date:20170717

branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-i386-pvgrub
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: 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:  linux 
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
  Bug introduced:  5771a8c08880cdca3bfb4a3fc6d309d6bba20877
  Bug not present: 3c2bfbaadff6e0c257bb6b16c9c97f43618b13dc
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/111919/


  (Revision log too long, omitted.)


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-linus/test-amd64-amd64-i386-pvgrub.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-amd64-i386-pvgrub.xen-boot
 --summary-out=tmp/111919.bisection-summary --basis-template=110515 
--blessings=real,real-bisect linux-linus test-amd64-amd64-i386-pvgrub xen-boot
Searching for failure / basis pass:
 111866 fail [host=chardonnay0] / 111800 [host=nobling0] 111771 [host=italia0] 
111739 [host=rimava1] 111714 [host=pinot1] 111677 [host=fiano0] 111654 
[host=huxelrebe1] 111635 [host=fiano1] 111611 [host=merlot0] 111580 
[host=baroque1] 111529 [host=godello1] 111493 [host=baroque0] 111416 
[host=nobling1] 111383 [host=elbling1] 111374 [host=chardonnay1] 111363 
[host=huxelrebe0] 111332 [host=godello0] 111280 [host=rimava0] 111222 
[host=nobling0] 83 [host=italia0] 48 [host=rimava1] 24 ok.
Failure / basis pass flights: 111866 / 24
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
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: 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 5771a8c08880cdca3bfb4a3fc6d309d6bba20877 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
8051789e982499050680a26febeada7467e18a8d 
414d069b38ab114b89085e44989bf57604ea86d7 
614a14736e33fb84872eb00f08799ebbc73a96c6
Basis pass 3c2bfbaadff6e0c257bb6b16c9c97f43618b13dc 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
8051789e982499050680a26febeada7467e18a8d 
414d069b38ab114b89085e44989bf57604ea86d7 
695bb5f504ab48c1d546446f104c1b6c0ead126d
Generating revisions with ./adhoc-revtuple-generator  
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git#3c2bfbaadff6e0c257bb6b16c9c97f43618b13dc-5771a8c08880cdca3bfb4a3fc6d309d6bba20877
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://xenbits.xen.org/qemu-xen-traditional.git#8051789e982499050680a26febeada7467e18a8d-8051789e982499050680a26febeada7467e18a8d
 
git://xenbits.xen.org/qemu-xen.git#414d069b38ab114b89085e44989bf57604ea86d7-414d069b38ab114b89085e44989bf57604ea86d7
 
git://xenbits.xen.org/xen.git#695bb5f504ab48c1d546446f104c1b6c0ead126d-614a14736e33fb84872eb00f08799ebbc73a96c6
adhoc-revtuple-generator: tree discontiguous: linux-2.6
Loaded 1002 nodes in revision graph
Searching for test results:
 110464 [host=italia0]
 110486 [host=chardonnay1]
 110515 [host=godello0]
 110547 [host=fiano1]
 110536 [host=baroque0]
 110560 [host=huxelrebe0]
 110908 [host=nobling1]
 110950 [host=fiano0]
 110984 [host=godello1]
 111081 [host=nocera1]
 24 pass 3c2bfbaadff6e0c257bb6b16c9c97f43618b13dc 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
8051789e982499050680a26febeada7467e18a8d 
414d069b38ab114b89085e44989bf57604ea86d7 
695bb5f504ab48c1d546446f104c1b6c0ead126d
 48 [host=rimava1]
 111280 [host=rimava0]
 83 [host=italia0]
 111222 [host=nobling0]
 111332 [host=godello0]
 111363 [host=huxelrebe0]
 111374 [host=chardonnay1]
 111383 [host=elbling1]
 111416 [host=nobling1]
 111493 [host=baroque0]
 111529 [host=godello1]
 111580 [host=baroque1]
 111611 [host=merlot0]
 111635 [host=fiano1]
 111654 [host=huxelrebe1]
 111677 [host=fiano0]
 111714 [host=pinot1]
 111739 [host=rimava1]
 111771 [host=italia0]
 111800 [host=nobling0]
 111831 fail irrelevant
 111866 fail 5771a8c08880cdca3bfb4a3fc6d309d6bba20877 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
8051789e982499050680a26febeada7467e18a8d 
414d069b38ab114b89085e44989bf57604ea86d7 
614a14736e33fb84872eb00f08799ebbc73a96c6
 111909 fail 5771a8c08880cdca3bfb4a3fc6d309d6bba20877 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
8051789e982499050680a26febeada7467e18a8d 
414d069b38ab114b89085e44989bf57604ea86d7 
614a14736e33fb84872eb00f08799ebbc73a96c6
 111911 pass 3c2bfbaadff6e0c257bb6b16c9c97f43618b13dc 
c530a75c1e6a47

Re: [Xen-devel] Tagging mini-os for Xen 4.8.2

On Thu, Jul 06, 2017 at 05:28:34PM +0100, Wei Liu wrote:
> Hi all
> 
> I'm checking which commit to tag for Xen 4.8.2. AFAICT there is only
> 1e8e464febb32 that can be considered a bug fix.
> 
> Normally what we do is we branch mini-os.git (stable-4.8) and backport
> the commit. However there is only one doc change between the commit
> we want and 4.8.1 tag. I propose we don't branch mini-os this time and
> tag 1e8e464febb32 directly.
> 
> If I hear no objection by the end of next week (July 14) I will proceed.

Nobody objects so I'm going to tag the tree today.

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

Re: [Xen-devel] preparations for 4.8.2

On Thu, Jul 06, 2017 at 01:17:02AM -0600, Jan Beulich wrote:
> All,
> 
> with the goal of releasing in the first half of August (once I'm back
> from vacation and had time to sync back up, and the tree has got
> the necessary push), please point out backport candidates you
> find missing from the respective staging branches, but which you
> consider relevant. Note that commit 2ff229643b ("livepatch: Don't
> crash on encountering STN_UNDEF relocations") is already on my
> list; I'm not fully decided on bd53b85156 ("livepatch: Use zeroed
> memory allocations for arrays") yet, but I tend towards taking it as
> long as it applies reasonably cleanly (which I expect it will do).
> 
> Thanks, Jan
> 

xen-RELEASE-4.8.2 tagged in mini-os.git.

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

Re: [Xen-devel] preparations for 4.8.2

2017-07-17 Thread Lars Kurth

Folks,

I didn't run the XSA script. Maybe someone can have a go and test out the
instructions in 
https://xenbits.xenproject.org/gitweb/?p=people/larsk/xen-release-scripts.g
it;a=summary
The scripts does requireS XSA.GIT to be checked out, but can be changed
easily to fetch XSAs from xenbits: line 26, and then follow $XSADIR

In fact --xsadir http://xenbits.xenproject.org/xsa may just work

Lars

On 17/07/2017, 10:01, "Wei Liu"  wrote:

>On Thu, Jul 06, 2017 at 01:17:02AM -0600, Jan Beulich wrote:
>> All,
>> 
>> with the goal of releasing in the first half of August (once I'm back
>> from vacation and had time to sync back up, and the tree has got
>> the necessary push), please point out backport candidates you
>> find missing from the respective staging branches, but which you
>> consider relevant. Note that commit 2ff229643b ("livepatch: Don't
>> crash on encountering STN_UNDEF relocations") is already on my
>> list; I'm not fully decided on bd53b85156 ("livepatch: Use zeroed
>> memory allocations for arrays") yet, but I tend towards taking it as
>> long as it applies reasonably cleanly (which I expect it will do).
>> 
>> Thanks, Jan
>> 
>
>xen-RELEASE-4.8.2 tagged in mini-os.git.

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

Re: [Xen-devel] [RFC PATCH 00/15] RFC: SGX virtualization design and draft patches

Hi Kai

Thanks for this nice write-up.

Some comments and questions below.

On Sun, Jul 09, 2017 at 08:03:10PM +1200, Kai Huang wrote:
> Hi all,
> 
[...]
> 2. SGX Virtualization Design
> 
> 2.1 High Level Toolstack Changes:
> 
> 2.1.1 New 'epc' parameter
> 
> EPC is limited resource. In order to use EPC efficiently among all domains,
> when creating guest, administrator should be able to specify domain's virtual
> EPC size. And admin
> alao should be able to get all domain's virtual EPC size.
> 
> For this purpose, a new 'epc = ' parameter is added to XL configuration
> file. This parameter specifies guest's virtual EPC size. The EPC base address
> will be calculated by toolstack internally, according to guest's memory size,
> MMIO size, etc. 'epc' is MB in unit and any 1MB aligned value will be 
> accepted.
> 
> 2.1.2 New XL commands (?)
> 
> Administrator should be able to get physical EPC size, and all domain's 
> virtual
> EPC size. For this purpose, we can introduce 2 additional commands:
> 
> # xl sgxinfo
> 
> Which will print out physical EPC size, and other SGX info (such as SGX1, 
> SGX2,
> etc) if necessary.
> 
> # xl sgxlist 
> 
> Which will print out particular domain's virtual EPC size, or list all virtual
> EPC sizes for all supported domains.
> 
> Alternatively, we can also extend existing XL commands by adding new option
> 
> # xl info -sgx
> 
> Which will print out physical EPC size along with other physinfo. And
> 
> # xl list  -sgx
> 
> Which will print out domain's virtual EPC size.
> 
> Comments?
> 

Can a guest have multiple EPC? If so, the proposed parameter is not good
enough.

Can a guest with EPC enabled be migrated? The answer to this question
can lead to multiple other questions.

Another question, is EPC going to be backed by normal memory? This is
related to memory accounting of the guest.

Is EPC going to be modeled as a device or another type of memory? This
is related to how we manage it in the toolstack.

Finally why do you not allow the users to specify the base address?

> In my RFC patches I didn't implement the commands as I don't know which
> is better. In the github repo I mentioned at the beginning, there's an old
> branch in which I implemented 'xl sgxinfo' and 'xl sgxlist', but they are
> implemented via dedicated hypercall for SGX, which I am not sure whether is a
> good option so I didn't include it in my RFC patches.
> 
> 2.1.3 Notify domain's virtual EPC base and size to Xen
> 
> Xen needs to know guest's EPC base and size in order to populate EPC pages for
> it. Toolstack notifies EPC base and size to Xen via XEN_DOMCTL_set_cpuid.
> 
> 2.1.4 Launch Control Support (?)
[...]
> 
> But maybe integrating EPC to MM framework is more reasonable. Comments?
> 
> 2.2.2 EPC Virtualization (?)
> 
> This part is how to populate EPC for guests. We have 3 choices:
> - Static Partitioning
> - Oversubscription
> - Ballooning
> 

IMHO static partitioning is good enough as a starting point.

Ballooning is nice to have but please don't make it mandatory. Not all
guests have balloon driver -- imagine a unikernel style secure domain
running with EPC.


> 
> 2.3 Additional Point: Live Migration, Snapshot Support (?)
> 

Oh, here it is. Nice.

> Actually from hardware's point of view, SGX is not migratable. There are two
> reasons:
> 
> - SGX key architecture cannot be virtualized.
> 
> For example, some keys are bound to CPU. For example, Sealing key, EREPORT
> key, etc. If VM is migrated to another machine, the same enclave will 
> derive
> the different keys. Taking Sealing key as an example, Sealing key is
> typically used by enclave (enclave can get sealing key by EGETKEY) to 
> *seal*
> its secrets to outside (ex, persistent storage) for further use. If 
> Sealing
> key changes after VM migration, then the enclave can never get the sealed
> secrets back by using sealing key, as it has changed, and old sealing key
> cannot be got back.
> 
> - There's no ENCLS to evict EPC page to normal memory, but at the meaning
> time, still keep content in EPC. Currently once EPC page is evicted, the 
> EPC
> page becomes invalid. So technically, we are unable to implement live
> migration (or check pointing, or snapshot) for enclave.
> 
> But, with some workaround, and some facts of existing SGX driver, technically
> we are able to support Live migration (or even check pointing, snapshot). This
> is because:
> 
> - Changing key (which is bound to CPU) is not a problem in reality
> 
> Take Sealing key as an example. Losing sealed data is not a problem, 
> because
> sealing key is only supposed to encrypt secrets that can be provisioned
> again. The typical work model is, enclave gets secrets provisioned from
> remote (service provider), and use sealing key to store it for further 
> use.
> When enclave tries to *unseal* use sealing key, if the sealing key is
> changed, enclave will fi

[Xen-devel] [distros-debian-sid test] 71695: tolerable trouble: blocked/broken/fail/pass

2017-07-17 Thread Platform Team regression test user

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-armhf-sid-netboot-pygrub  1 build-check(1)blocked n/a
 build-arm64-pvops 2 hosts-allocate   broken like 71677
 build-arm64   2 hosts-allocate   broken like 71677
 build-arm64-pvops 3 capture-logs broken like 71677
 build-arm64   3 capture-logs broken like 71677
 test-amd64-i386-i386-sid-netboot-pvgrub 11 guest-start fail like 71677
 test-amd64-amd64-amd64-sid-netboot-pvgrub 11 guest-start   fail like 71677
 test-amd64-i386-amd64-sid-netboot-pygrub 11 guest-startfail like 71677
 test-armhf-armhf-armhf-sid-netboot-pygrub 10 debian-di-install fail like 71677

baseline version:
 flight   71677

jobs:
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-arm64-pvopsbroken  
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-sid-netboot-pvgrubfail
 test-amd64-i386-i386-sid-netboot-pvgrub  fail
 test-amd64-i386-amd64-sid-netboot-pygrub fail
 test-arm64-arm64-armhf-sid-netboot-pygrubblocked 
 test-armhf-armhf-armhf-sid-netboot-pygrubfail
 test-amd64-amd64-i386-sid-netboot-pygrub pass



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

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

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


Push not applicable.


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

Re: [Xen-devel] Notes on stubdoms and latency on ARM

On 07/12/2017 07:14 AM, Dario Faggioli wrote:
> On Fri, 2017-07-07 at 14:12 -0700, Stefano Stabellini wrote:
>> On Fri, 7 Jul 2017, Volodymyr Babchuk wrote:
>
 Since you are using Credit, can you try to disable context switch
 rate
 limiting?
>>>
>>> Yep. You are right. In the environment described above (Case 2) I
>>> now
>>> get much better results:
>>>
>>>  real 1.85
>>> user 0.00
>>> sys 1.85
>>
>> From 113 to 1.85 -- WOW!
>>
>> Obviously I am no scheduler expert, but shouldn't we advertise a bit
>> better a scheduler configuration option that makes things _one
>> hundred
>> times faster_ ?! 
>>
> So, to be fair, so far, we've bitten this hard by this only on
> artificially constructed test cases, where either some extreme
> assumption were made (e.g., that all the vCPUs except one always run at
> 100% load) or pinning was used in a weird and suboptimal way. And there
> are workload where it has been verified that it helps making
> performance better (poor SpecVIRT  results without it was the main
> motivation having it upstream, and on by default).
> 
> That being said, I personally have never liked rate-limiting, it always
> looked to me like the wrong solution.

In fact, I *think* the only reason it may have been introduced is that
there was a bug in the credit2 code at the time such that it always had
a single runqueue no matter what your actual pcpu topology was.

>> It's not even mentioned in
>> https://wiki.xen.org/wiki/Tuning_Xen_for_Performance!
>>
> Well, for sure it should be mentioned here, you're right!
> 
>> Also, it is worrying to me that there are cases were, unless the user
>> tweaks the configuration, she is going to get 100x worse performance
>> out
>> of her system.
>>
> As I said, it's hard to tell in advance whether it will have a good,
> bad, or really bad impact on a specific workload.
> 
> I'm starting to think, though, that it may be good to switch to having
> it off by default, and then document that if the system is going into
> trashing because of too frequent context switches, turning it on may
> help.
> 
> I'll think about it, and see if I'll be able to run some benchmarks
> with it on and off.

Thanks.  FYI the main benchmark that was used to justify its inclusion
(and on by default) was specvirt (I think).

 -George

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

[Xen-devel] [XenSummit 2017] Notes from the PVH toolstack interface session

Hello,

I didn't actually take notes, so this is from the top of my head. If
anyone took notes or remember something different, please feel free to
correct it.

This is the output from the PVH toolstack interface session. The
participants where: Ian Jackson, Wei Liu, George Dunlap, Vincent
Legout and myself.

We agreed on the following interface for xl configuration files:

type = "hvm | pv | pvh"

This is going to supersede the "builder" option present in xl. Both
options are mutually exclusive. The "builder" option is going to be
marked as deprecated once the new "type" option is implemented.

In order to decide how to boot the guest the following options will be
available. Note that they are mutually exclusive.

kernel = ""
ramdisk = ""
cmdline = ""

: relative or full path in the filesystem.

Boot directly into the kernel/ramdisk provided. In this case the
kernel must be available somewhere in the toolstack filesystem
hierarchy.

firmware = "ovmf | uefi | bios | seabios | rombios | pvgrub"

This allows to load a firmware inside of the guest and run it in guest
mode. Note that the firmware needs to support booting in PVH mode.

There's no plan to support any bios or pvgrub ATM for PVH, those
options are simply listed for completeness. Also, generic options like
uefi or bios would be aliases to a concrete implementation by the
toolstack, ie: uefi -> ovmf, bios -> seabios most likely.

bootloader = "pygrub"

Run a specific binary in the toolstack domain that's going to provide
a kernel, ramdisk and cmdline as output. This is mostly pygrub, that
accesses the guest disk image and extracts the kernel/ramdisk/cmdline
from it.

We also spoke about the libxl interface. This is going to require
changes to libxl_domain_build_info, which obviously need to be
performed in an API compatible way.

A new libxl_domain_type needs to be added (PVH) and the new "type"
config option is going to map to the "type" field in the
libxl_domain_create_info struct.

While looking at the contents of the libxl_domain_build_info we
realized that there was a bunch of duplication between the
domain-specific fields and the top level ones. Ie: there's a top level
"kernel" field and one inside of the pv nested structure. It would be
interesting to prevent adding a new pvh structure, and instead move
all the fields to the top level structure (libxl_domain_build_info).

I think that's all of it, as said in the beginning, if anything is
missing feel free to add it.

Regarding the implementation work itself, I'm currently quite busy
with other PVH stuff, so I would really appreciate if someone could
take care of this.

I think this should be merged in 4.10, so that the toolstack finally
has a stable interface to create PVH guests and we can start
announcing this. Without this work, even if the PVH DomU ABI is
stable, there's no way anyone is going to use it.

Thanks, Roger.

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

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

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-win7-amd64 10 windows-install   fail REGR. vs. 111765
 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install   fail REGR. vs. 111765
 test-amd64-amd64-xl-qemuu-win7-amd64 10 windows-install  fail REGR. vs. 111765

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

version targeted for testing:
 qemuu4871b51b9241b10f4fd8e04bbb21577886795e25
baseline version:
 qemuu31fe1c414501047cbb91b695bdccc0068496dcf6

Last test of basis   111765  2017-07-13 10:20:16 Z3 days
Failing since111790  2017-07-14 04:20:46 Z3 days4 attempts
Testing same since   111817  2017-07-14 22:31:31 Z2 days3 attempts


People who touched revisions under test:
  Alex BennÃ©e 
  Alexander Graf 
  Alexey Kardashevskiy 
  Alistair Francis 
  Anthony PERARD 
  Anton Nefedov 
  Aurelien Jarno 
  Christian Borntraeger 
  Claudio Imbrenda 
  Cornelia Huck 
  Cornelia Huck 
  CÃ©dric Le Goater 
  Daniel P. Berrange 
  David Gibson 
  Denis V. Lunev 
  Dr. David Alan Gilbert 
  Eduardo Habkost 
  Emilio G. Cota 
  Eric Blake 
  Fam Zheng 
  Fan Zhang 
  Farhan Ali 
  Fei Li 
  Gerd Hoffmann 
  Greg Kurz 
  Halil Pasic 
  Igor Mammedov 
  Janosch Frank 
  Jason J. Herne 
  Joel Stanley 
  Krzysztof Kozlowski

Re: [Xen-devel] [PATCH v9 7/7] tools/xen-mceinj: add support of injecting LMCE

On Thu, Jul 13, 2017 at 10:10:05AM +0800, Haozhong Zhang wrote:
> On 07/12/17 09:26 -0400, Konrad Rzeszutek Wilk wrote:
> > On Wed, Jul 12, 2017 at 10:04:40AM +0800, Haozhong Zhang wrote:
> > > If option '-l' or '--lmce' is specified and the host supports LMCE,
> > > xen-mceinj will inject LMCE to CPU specified by '-c' (or CPU0 if '-c'
> > > is not present).
> > > 
> > > Signed-off-by: Haozhong Zhang 
> > > Acked-by: Wei Liu 
> > > ---
> > > Cc: Ian Jackson 
> > > Cc: Wei Liu 
> > > ---
> > >  tools/tests/mce-test/tools/xen-mceinj.c | 50 
> > > +++--
> > >  1 file changed, 48 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/tools/tests/mce-test/tools/xen-mceinj.c 
> > > b/tools/tests/mce-test/tools/xen-mceinj.c
> > > index bae5a46eb5..380e42190c 100644
> > > --- a/tools/tests/mce-test/tools/xen-mceinj.c
> > > +++ b/tools/tests/mce-test/tools/xen-mceinj.c
> [..]
> > >  
> > > +static int inject_lmce(xc_interface *xc_handle, unsigned int cpu)
> > > +{
> > > +uint8_t *cpumap = NULL;
> > > +size_t cpumap_size, line, shift;
> > > +unsigned int nr_cpus;
> > > +int ret;
> > > +
> > > +nr_cpus = mca_cpuinfo(xc_handle);
> > > +if ( !nr_cpus )
> > > +err(xc_handle, "Failed to get mca_cpuinfo");
> > > +if ( cpu >= nr_cpus )
> > > +err(xc_handle, "-c %u is larger than %u", cpu, nr_cpus - 1);
> > > +
> > > +cpumap_size = (nr_cpus + 7) / 8;
> > 
> > bitmap_size
> >
> 
> IIUC, these bitmap_* functions/macros are libxc internals and should
> not be used here.
> 

Correct. Those aren't available to external users. If we want to export
those we would need to add libxc_ prefix.

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

Re: [Xen-devel] Notes on stubdoms and latency on ARM


Hi,

On 17/07/17 10:25, George Dunlap wrote:

On 07/12/2017 07:14 AM, Dario Faggioli wrote:

On Fri, 2017-07-07 at 14:12 -0700, Stefano Stabellini wrote:

On Fri, 7 Jul 2017, Volodymyr Babchuk wrote:



Since you are using Credit, can you try to disable context switch
rate
limiting?


Yep. You are right. In the environment described above (Case 2) I
now
get much better results:

 real 1.85
user 0.00
sys 1.85


From 113 to 1.85 -- WOW!

Obviously I am no scheduler expert, but shouldn't we advertise a bit
better a scheduler configuration option that makes things _one
hundred
times faster_ ?!


So, to be fair, so far, we've bitten this hard by this only on
artificially constructed test cases, where either some extreme
assumption were made (e.g., that all the vCPUs except one always run at
100% load) or pinning was used in a weird and suboptimal way. And there
are workload where it has been verified that it helps making
performance better (poor SpecVIRT  results without it was the main
motivation having it upstream, and on by default).

That being said, I personally have never liked rate-limiting, it always
looked to me like the wrong solution.


In fact, I *think* the only reason it may have been introduced is that
there was a bug in the credit2 code at the time such that it always had
a single runqueue no matter what your actual pcpu topology was.


FWIW, we don't yet parse the pCPU topology on ARM. AFAIU, we always tell 
Xen each CPU is in its own core. Will it have some implications in the 
scheduler?


Cheers,

--
Julien Grall

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

[Xen-devel] [XenSummit 2017] Notes from the PVH performance session

Hey,

I took a few notes at the PVH performance session at the summit.
I hope there isn't any major stuff missing...

Participants (at least naming the active ones): Andrew Cooper,
Jan Beulich, Paul Durrant, Roger Pau Monné and myself (the list is
just from my memory).

Following performance problems with PVH, especially when being used
as Dom0 or in driver domains, have been named to expected:

- Domain creation will be slower compared to PV Dom0, as especially
  hypercalls are much more expensive in PVH. Most calls into the
  hypervisor will result from hypercall continuations. Measurements
  with a PVH Dom0 based on BSD by Roger showed a slowdown of about
  factor 3-4 for domain creation.

- Live migration will have the same issues as domain creation,
  additionally mapping/unmapping the guest's memory will add more
  overhead.

- Backends for PV devices will suffer from worse hypercall performance
  as well, especially event channel operations, maps and unmaps have
  been named.

The following tuning options have been suggested:

- For live migration add a "mem copy" option similar to "grant copy".
  This avoids one hypercall compared to "map, copy, unmap" done today.

- For domain creation a possible solution could be a service domain
  doing the major amount of hypercalls (this service domain would be
  PV again, so Wei's idea of PV inside of a PVH container is no
  option then). Other ideas are asynchronous hypercalls (via a
  hypercall ring), but this would require some kind of service-vcpu
  in the hypervisor.
  This topic has to be discussed further.

- Backend performance could be enhanced by using "grant copy" instead
  of "map, use, unmap". OTOH this adds the need for bounce buffers.
  Depending on the backend type this might be a good idea, though.

- A general way to speed up some hypercalls might be the handling of
  hypercall parameters: for some hypercalls parameters could be passed
  in registers instead of guest memory. This would remove the need for
  walking the guest's page tables when retrieving those parameters.
  Hypercalls requiring memory parameters can be sped up by registering
  the memory buffers and just referencing those buffers when doing the
  hypercalls. The buffers could be kept mapped in the hypervisor so
  again there would be no need to walk the guest's pagetables on a hot
  path. Another possibility would be to use guest physical addresses
  as hypercall parameters.
  This should be sorted out and implemented in 4.10 IMO.

I hope I didn't forget anything.


Juergen

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

Re: [Xen-devel] [XenSummit 2017] Notes from the PVH toolstack interface session

On 17/07/17 10:36, Roger Pau Monné wrote:
> Hello,
>
> I didn't actually take notes, so this is from the top of my head. If
> anyone took notes or remember something different, please feel free to
> correct it.
>
> This is the output from the PVH toolstack interface session. The
> participants where: Ian Jackson, Wei Liu, George Dunlap, Vincent
> Legout and myself.
>
> We agreed on the following interface for xl configuration files:
>
> type = "hvm | pv | pvh"
>
> This is going to supersede the "builder" option present in xl. Both
> options are mutually exclusive. The "builder" option is going to be
> marked as deprecated once the new "type" option is implemented.
>
> In order to decide how to boot the guest the following options will be
> available. Note that they are mutually exclusive.

I presume you mean the kernel/ramdisk/cmdline are mutually exclusive
with firmware?

> kernel = ""
> ramdisk = ""
> cmdline = ""
>
> : relative or full path in the filesystem.

Please can xl or libxl's (not entirely sure which) path handling be
fixed as part of this work.  As noted in
http://xenbits.xen.org/docs/xtf/index.html#errata, path handling is
inconsistent as to whether it allows paths relative to the .cfg file. 
All paths should support being relative to the cfg file, as that is the
most convenient for the end user to use.

> Boot directly into the kernel/ramdisk provided. In this case the
> kernel must be available somewhere in the toolstack filesystem
> hierarchy.
>
> firmware = "ovmf | uefi | bios | seabios | rombios | pvgrub"

What is the purpose of having uefi and bios in there?  ovmf is the uefi
implementation, and {rom,sea}bios are the bios implementations.

How does someone specify ovmf + seabios as a CSM?

> This allows to load a firmware inside of the guest and run it in guest
> mode. Note that the firmware needs to support booting in PVH mode.
>
> There's no plan to support any bios or pvgrub ATM for PVH, those
> options are simply listed for completeness. Also, generic options like
> uefi or bios would be aliases to a concrete implementation by the
> toolstack, ie: uefi -> ovmf, bios -> seabios most likely.

Oh - here is the reason.  -1 to this idea.  We don't want to explicitly
let people choose options which are liable to change under their feet if
they were to boot the same .cfg file on a newer version of Xen, as their
VM will inevitable break.

> bootloader = "pygrub"
>
> Run a specific binary in the toolstack domain that's going to provide
> a kernel, ramdisk and cmdline as output. This is mostly pygrub, that
> accesses the guest disk image and extracts the kernel/ramdisk/cmdline
> from it.
>
> We also spoke about the libxl interface. This is going to require
> changes to libxl_domain_build_info, which obviously need to be
> performed in an API compatible way.
>
> A new libxl_domain_type needs to be added (PVH) and the new "type"
> config option is going to map to the "type" field in the
> libxl_domain_create_info struct.
>
> While looking at the contents of the libxl_domain_build_info we
> realized that there was a bunch of duplication between the
> domain-specific fields and the top level ones. Ie: there's a top level
> "kernel" field and one inside of the pv nested structure. It would be
> interesting to prevent adding a new pvh structure, and instead move
> all the fields to the top level structure (libxl_domain_build_info).
>
> I think that's all of it, as said in the beginning, if anything is
> missing feel free to add it.
>
> Regarding the implementation work itself, I'm currently quite busy
> with other PVH stuff, so I would really appreciate if someone could
> take care of this.
>
> I think this should be merged in 4.10, so that the toolstack finally
> has a stable interface to create PVH guests and we can start
> announcing this. Without this work, even if the PVH DomU ABI is
> stable, there's no way anyone is going to use it.

Some other questions.

Where does hvmloader fit into this mix?

How does firmware_override= work in this new world?  How about firmware=
taking a  to allow for easy testing of custom binaries?

Instead of kernel= and ramdisk=, it would be better to generalise to
something like modules=[...], perhaps with kernel being an alias for
module[0] etc.  hvmloader already takes multiple binaries using the PVH
module system, and PV guests are perfectly capable of multiple modules
as well.  One specific example where an extra module would be very
helpful is for providing the cloudinit install config file.

~Andrew

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

Re: [Xen-devel] [XenSummit 2017] Notes from the PVH performance session

On 17/07/17 11:09, Juergen Gross wrote:
> Hey,
>
> I took a few notes at the PVH performance session at the summit.
> I hope there isn't any major stuff missing...
>
> Participants (at least naming the active ones): Andrew Cooper,
> Jan Beulich, Paul Durrant, Roger Pau Monné and myself (the list is
> just from my memory).
>
> Following performance problems with PVH, especially when being used
> as Dom0 or in driver domains, have been named to expected:
>
> - Domain creation will be slower compared to PV Dom0, as especially
>   hypercalls are much more expensive in PVH. Most calls into the
>   hypervisor will result from hypercall continuations. Measurements
>   with a PVH Dom0 based on BSD by Roger showed a slowdown of about
>   factor 3-4 for domain creation.
>
> - Live migration will have the same issues as domain creation,
>   additionally mapping/unmapping the guest's memory will add more
>   overhead.
>
> - Backends for PV devices will suffer from worse hypercall performance
>   as well, especially event channel operations, maps and unmaps have
>   been named.
>
> The following tuning options have been suggested:
>
> - For live migration add a "mem copy" option similar to "grant copy".
>   This avoids one hypercall compared to "map, copy, unmap" done today.

I presume you mean "This would be one single hypercall as opposed to the
three done today" ?

>
> - For domain creation a possible solution could be a service domain
>   doing the major amount of hypercalls (this service domain would be
>   PV again, so Wei's idea of PV inside of a PVH container is no
>   option then). Other ideas are asynchronous hypercalls (via a
>   hypercall ring), but this would require some kind of service-vcpu
>   in the hypervisor.
>   This topic has to be discussed further.
>
> - Backend performance could be enhanced by using "grant copy" instead
>   of "map, use, unmap". OTOH this adds the need for bounce buffers.
>   Depending on the backend type this might be a good idea, though.
>
> - A general way to speed up some hypercalls might be the handling of
>   hypercall parameters: for some hypercalls parameters could be passed
>   in registers instead of guest memory. This would remove the need for
>   walking the guest's page tables when retrieving those parameters.
>   Hypercalls requiring memory parameters can be sped up by registering
>   the memory buffers and just referencing those buffers when doing the
>   hypercalls. The buffers could be kept mapped in the hypervisor so
>   again there would be no need to walk the guest's pagetables on a hot
>   path. Another possibility would be to use guest physical addresses
>   as hypercall parameters.
>   This should be sorted out and implemented in 4.10 IMO.

And some initial patches have already been posted :)

~Andrew

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

Re: [Xen-devel] [XenSummit 2017] Notes from the PVH performance session

On 17/07/17 12:15, Andrew Cooper wrote:
> On 17/07/17 11:09, Juergen Gross wrote:
>> Hey,
>>
>> I took a few notes at the PVH performance session at the summit.
>> I hope there isn't any major stuff missing...
>>
>> Participants (at least naming the active ones): Andrew Cooper,
>> Jan Beulich, Paul Durrant, Roger Pau Monné and myself (the list is
>> just from my memory).
>>
>> Following performance problems with PVH, especially when being used
>> as Dom0 or in driver domains, have been named to expected:
>>
>> - Domain creation will be slower compared to PV Dom0, as especially
>>   hypercalls are much more expensive in PVH. Most calls into the
>>   hypervisor will result from hypercall continuations. Measurements
>>   with a PVH Dom0 based on BSD by Roger showed a slowdown of about
>>   factor 3-4 for domain creation.
>>
>> - Live migration will have the same issues as domain creation,
>>   additionally mapping/unmapping the guest's memory will add more
>>   overhead.
>>
>> - Backends for PV devices will suffer from worse hypercall performance
>>   as well, especially event channel operations, maps and unmaps have
>>   been named.
>>
>> The following tuning options have been suggested:
>>
>> - For live migration add a "mem copy" option similar to "grant copy".
>>   This avoids one hypercall compared to "map, copy, unmap" done today.
> 
> I presume you mean "This would be one single hypercall as opposed to the
> three done today" ?

One instead of the two of today (copy isn't a hypercall, of course). So
one hypercall would be avoided.

>> - For domain creation a possible solution could be a service domain
>>   doing the major amount of hypercalls (this service domain would be
>>   PV again, so Wei's idea of PV inside of a PVH container is no
>>   option then). Other ideas are asynchronous hypercalls (via a
>>   hypercall ring), but this would require some kind of service-vcpu
>>   in the hypervisor.
>>   This topic has to be discussed further.
>>
>> - Backend performance could be enhanced by using "grant copy" instead
>>   of "map, use, unmap". OTOH this adds the need for bounce buffers.
>>   Depending on the backend type this might be a good idea, though.
>>
>> - A general way to speed up some hypercalls might be the handling of
>>   hypercall parameters: for some hypercalls parameters could be passed
>>   in registers instead of guest memory. This would remove the need for
>>   walking the guest's page tables when retrieving those parameters.
>>   Hypercalls requiring memory parameters can be sped up by registering
>>   the memory buffers and just referencing those buffers when doing the
>>   hypercalls. The buffers could be kept mapped in the hypervisor so
>>   again there would be no need to walk the guest's pagetables on a hot
>>   path. Another possibility would be to use guest physical addresses
>>   as hypercall parameters.
>>   This should be sorted out and implemented in 4.10 IMO.
> 
> And some initial patches have already been posted :)

Indeed. :-)


Juergen

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

Re: [Xen-devel] [XenSummit 2017] Notes from the PVH toolstack interface session

On Mon, Jul 17, 2017 at 11:10:50AM +0100, Andrew Cooper wrote:
> On 17/07/17 10:36, Roger Pau Monné wrote:
> > Hello,
> >
> > I didn't actually take notes, so this is from the top of my head. If
> > anyone took notes or remember something different, please feel free to
> > correct it.
> >
> > This is the output from the PVH toolstack interface session. The
> > participants where: Ian Jackson, Wei Liu, George Dunlap, Vincent
> > Legout and myself.
> >
> > We agreed on the following interface for xl configuration files:
> >
> > type = "hvm | pv | pvh"
> >
> > This is going to supersede the "builder" option present in xl. Both
> > options are mutually exclusive. The "builder" option is going to be
> > marked as deprecated once the new "type" option is implemented.
> >
> > In order to decide how to boot the guest the following options will be
> > available. Note that they are mutually exclusive.
> 
> I presume you mean the kernel/ramdisk/cmdline are mutually exclusive
> with firmware?

Yes, sorry that's confusing. Either you use kernel, firmware or
bootloader.

> > kernel = ""
> > ramdisk = ""
> > cmdline = ""
> >
> > : relative or full path in the filesystem.
> 
> Please can xl or libxl's (not entirely sure which) path handling be
> fixed as part of this work.  As noted in
> http://xenbits.xen.org/docs/xtf/index.html#errata, path handling is
> inconsistent as to whether it allows paths relative to the .cfg file. 
> All paths should support being relative to the cfg file, as that is the
> most convenient for the end user to use.
> 
> > Boot directly into the kernel/ramdisk provided. In this case the
> > kernel must be available somewhere in the toolstack filesystem
> > hierarchy.
> >
> > firmware = "ovmf | uefi | bios | seabios | rombios | pvgrub"
> 
> What is the purpose of having uefi and bios in there?  ovmf is the uefi
> implementation, and {rom,sea}bios are the bios implementations.
> 
> How does someone specify ovmf + seabios as a CSM?

Hm, I have no idea. How is this done usually, is ovmf built with
seabios support, or is it fetched by ovmf from the uefi partition?

> > This allows to load a firmware inside of the guest and run it in guest
> > mode. Note that the firmware needs to support booting in PVH mode.
> >
> > There's no plan to support any bios or pvgrub ATM for PVH, those
> > options are simply listed for completeness. Also, generic options like
> > uefi or bios would be aliases to a concrete implementation by the
> > toolstack, ie: uefi -> ovmf, bios -> seabios most likely.
> 
> Oh - here is the reason.  -1 to this idea.  We don't want to explicitly
> let people choose options which are liable to change under their feet if
> they were to boot the same .cfg file on a newer version of Xen, as their
> VM will inevitable break.

Noted, I think not allowing bios or uefi is fine, I would rather
document in the man page that our recommended bios implementation is
seabios and the uefi one ovmf.

> > bootloader = "pygrub"
> >
> > Run a specific binary in the toolstack domain that's going to provide
> > a kernel, ramdisk and cmdline as output. This is mostly pygrub, that
> > accesses the guest disk image and extracts the kernel/ramdisk/cmdline
> > from it.
> >
> > We also spoke about the libxl interface. This is going to require
> > changes to libxl_domain_build_info, which obviously need to be
> > performed in an API compatible way.
> >
> > A new libxl_domain_type needs to be added (PVH) and the new "type"
> > config option is going to map to the "type" field in the
> > libxl_domain_create_info struct.
> >
> > While looking at the contents of the libxl_domain_build_info we
> > realized that there was a bunch of duplication between the
> > domain-specific fields and the top level ones. Ie: there's a top level
> > "kernel" field and one inside of the pv nested structure. It would be
> > interesting to prevent adding a new pvh structure, and instead move
> > all the fields to the top level structure (libxl_domain_build_info).
> >
> > I think that's all of it, as said in the beginning, if anything is
> > missing feel free to add it.
> >
> > Regarding the implementation work itself, I'm currently quite busy
> > with other PVH stuff, so I would really appreciate if someone could
> > take care of this.
> >
> > I think this should be merged in 4.10, so that the toolstack finally
> > has a stable interface to create PVH guests and we can start
> > announcing this. Without this work, even if the PVH DomU ABI is
> > stable, there's no way anyone is going to use it.
> 
> Some other questions.
> 
> Where does hvmloader fit into this mix?

Right, I wasn't planning anyone using hvmloader, but there's no reason
to prevent it. I guess it would fit into the "firmware" option, but
then you should be able to use something like: firmware = "hvmloader +
ovmf".

What would be the purpose of using hvmloader inside of a PVH guest?
Hardware initialization?

> How does firmware_override= work in this new

Re: [Xen-devel] preparations for 4.8.2

On Mon, Jul 17, 2017 at 09:17:23AM +0100, Lars Kurth wrote:
> Folks,
> 
> I didn't run the XSA script. Maybe someone can have a go and test out the
> instructions in 
> https://xenbits.xenproject.org/gitweb/?p=people/larsk/xen-release-scripts.g
> it;a=summary
> The scripts does requireS XSA.GIT to be checked out, but can be changed
> easily to fetch XSAs from xenbits: line 26, and then follow $XSADIR
> 
> In fact --xsadir http://xenbits.xenproject.org/xsa may just work
> 
> Lars
> 

I tried to follow the instructions in README for match-xsa. I believe
the xsa-list-send script in step 3 depends on xsa.git, which I don't
have access to.

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

[Xen-devel] [XenSummit 2017] Notes from the 5-level-paging session

Hey,

I took a few notes at the 5-level-paging session at the summit.
I hope there isn't any major stuff missing...

Participants (at least naming the active ones): Andrew Cooper,
Jan Beulich, Yu Zhang and myself (the list is just from my memory).

The following topics have been discussed in the session:


1. Do we need support for 5-level-paging PV guests?

There is no urgent need for 5-level-paging PV guests for the
following reasons:

- Guests >64TB (which is the upper limit for 4-level-paging Linux)
  can be PVH or HVM.

- A 5-level-paging host supports up to 4 PB physical memory. A
  4-level-paging PV-Dom0 can support that theoretically: the M2P map
  for 4 PB memory needs 8 TB space, which just fits into the hypervisor
  reserved memory area in the Linux kernel. Any other hypervisor data
  and/or code can live in the additionally available virtual space of
  the 5-level-paging mode.

There was agreement we don't need support of 5-level-paging PV guests
right now. There is a need, however, to support 4-level-paging PV
guests located anywhere in the 52-bit physical space of a 5-level-paging
host (right now they would have to be in the bottom 64 TB as the Linux
kernel is masking away any MFN bit above 64 TB). I will send patches to
support this.


2. Do we need 5-level-paging shadow mode support?

While strictly required for PV guests only and no 5-level-paging PV
guests are to be supported, we will need 5-level-paging shadow mode in
the long run. This is necessary because even for a 4-level-paging PV
guest (or a 32-bit PV guest) the processor will run in 5-level-paging
mode on a huge host as switching between the paging modes is rather
complicated and should be avoided. It is much easier to run shadow
mode for the whole page table tree instead for two subtrees only.

OTOH the first step when implementing 5-level-paging in the hypervisor
doesn't require shadow mode to be working, so it can be omitted in the
beginning.


3. Is it possible to support 5-level-paging in Xen via a specific
   binary for the first step?

Yu Zhang asked for implementing 5-level-paging via a Kconfig option
instead of dynamical switching at boot time for the first prototype.
This request was accepted in order to reduce the complexity of the
initial patches. Boot time switching should be available for the
final solution, though.


I hope I didn't miss anything.


Juergen

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

Re: [Xen-devel] [PATCH 15/15] xen: tools: expose EPC in ACPI table

On Sun, Jul 09, 2017 at 08:16:05PM +1200, Kai Huang wrote:
> On physical machine EPC is exposed in ACPI table via "INT0E0C". Although EPC
> can be discovered by CPUID but Windows driver requires EPC to be exposed in
> ACPI table as well. This patch exposes EPC in ACPI table.
> 
> Signed-off-by: Kai Huang 
> ---
>  tools/firmware/hvmloader/util.c  | 23 +++
>  tools/firmware/hvmloader/util.h  |  3 +++

Is there any reason this needs to be done in hvmloader instead of
libacpi? I'm mostly asking this because PVH guests can also get ACPI
tables, so it would be good to be able to expose EPC to them using
ACPI.

Thanks, Roger.

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

Re: [Xen-devel] [XenSummit 2017] Notes from the PVH toolstack interface session

On 07/17/2017 10:36 AM, Roger Pau Monné wrote:
> Hello,
> 
> I didn't actually take notes, so this is from the top of my head. If
> anyone took notes or remember something different, please feel free to
> correct it.
> 
> This is the output from the PVH toolstack interface session. The
> participants where: Ian Jackson, Wei Liu, George Dunlap, Vincent
> Legout and myself.
> 
> We agreed on the following interface for xl configuration files:
> 
> type = "hvm | pv | pvh"
> 
> This is going to supersede the "builder" option present in xl. Both
> options are mutually exclusive. The "builder" option is going to be
> marked as deprecated once the new "type" option is implemented.
> 
> In order to decide how to boot the guest the following options will be
> available. Note that they are mutually exclusive.
> 
> kernel = ""
> ramdisk = ""
> cmdline = ""
> 
> : relative or full path in the filesystem.
> 
> Boot directly into the kernel/ramdisk provided. In this case the
> kernel must be available somewhere in the toolstack filesystem
> hierarchy.
> 
> firmware = "ovmf | uefi | bios | seabios | rombios | pvgrub"
> 
> This allows to load a firmware inside of the guest and run it in guest
> mode. Note that the firmware needs to support booting in PVH mode.
> 
> There's no plan to support any bios or pvgrub ATM for PVH, those
> options are simply listed for completeness.

FYI there was a *lot* of interest in PVGRUB for PVH at the hackathon.
If we can prod the person who did the first PV grub port (pvgrub2 as
it's sometimes called) to do the same for PVH I think it would be an
important feature.

Everything else looks good to me.

 -George

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

[Xen-devel] [PATCH v2] xenconsole: Add pipe option

2017-07-17 Thread Felix Schmoll

Add pipe option to xenconsole that forwards console input.

Signed-off-by: Felix Schmoll 

---
Changed since v1:
  * introduce separate pipe flag
  * remove changes to libxl
---
 tools/console/client/main.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/tools/console/client/main.c b/tools/console/client/main.c
index 99f034..84a466c32f 100644
--- a/tools/console/client/main.c
+++ b/tools/console/client/main.c
@@ -334,6 +334,7 @@ int main(int argc, char **argv)
{ "num", 1, 0, 'n' },
{ "help",0, 0, 'h' },
{ "start-notify-fd", 1, 0, 's' },
+   { "pipe", 0, 0, 'p' },
{ 0 },
 
};
@@ -343,6 +344,7 @@ int main(int argc, char **argv)
char *end;
console_type type = CONSOLE_INVAL;
bool interactive = 0;
+   bool pipe = 0;
 
if (isatty(STDIN_FILENO) && isatty(STDOUT_FILENO))
interactive = 1;
@@ -370,6 +372,9 @@ int main(int argc, char **argv)
case 's':
start_notify_fd = atoi(optarg);
break;
+case 'p':
+pipe = 1;
+break;
default:
fprintf(stderr, "Invalid argument\n");
fprintf(stderr, "Try `%s --help' for more 
information.\n", 
@@ -484,7 +489,7 @@ int main(int argc, char **argv)
close(start_notify_fd);
}
 
-   console_loop(spty, xs, path, interactive);
+   console_loop(spty, xs, path, interactive || pipe);
 
free(path);
free(dom_path);
-- 
2.11.0


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

Re: [Xen-devel] [PATCH] IOMMU/PCI: make a few functions static

On Fri, Jul 14, 2017 at 08:05:05AM -0600, Jan Beulich wrote:
> Add forward declarations in order to not move things around.
> 
> Signed-off-by: Jan Beulich 

Reviewed-by: Roger Pau Monné 

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

Re: [Xen-devel] [XenSummit 2017] Notes from the PVH toolstack interface session

On 07/17/2017 11:37 AM, Roger Pau Monné wrote:
> On Mon, Jul 17, 2017 at 11:10:50AM +0100, Andrew Cooper wrote:
>> On 17/07/17 10:36, Roger Pau Monné wrote:
>>> Hello,
>>>
>>> I didn't actually take notes, so this is from the top of my head. If
>>> anyone took notes or remember something different, please feel free to
>>> correct it.
>>>
>>> This is the output from the PVH toolstack interface session. The
>>> participants where: Ian Jackson, Wei Liu, George Dunlap, Vincent
>>> Legout and myself.
>>>
>>> We agreed on the following interface for xl configuration files:
>>>
>>> type = "hvm | pv | pvh"
>>>
>>> This is going to supersede the "builder" option present in xl. Both
>>> options are mutually exclusive. The "builder" option is going to be
>>> marked as deprecated once the new "type" option is implemented.
>>>
>>> In order to decide how to boot the guest the following options will be
>>> available. Note that they are mutually exclusive.
>>
>> I presume you mean the kernel/ramdisk/cmdline are mutually exclusive
>> with firmware?
> 
> Yes, sorry that's confusing. Either you use kernel, firmware or
> bootloader.
> 
>>> kernel = ""
>>> ramdisk = ""
>>> cmdline = ""
>>>
>>> : relative or full path in the filesystem.
>>
>> Please can xl or libxl's (not entirely sure which) path handling be
>> fixed as part of this work.  As noted in
>> http://xenbits.xen.org/docs/xtf/index.html#errata, path handling is
>> inconsistent as to whether it allows paths relative to the .cfg file. 
>> All paths should support being relative to the cfg file, as that is the
>> most convenient for the end user to use.
>>
>>> Boot directly into the kernel/ramdisk provided. In this case the
>>> kernel must be available somewhere in the toolstack filesystem
>>> hierarchy.
>>>
>>> firmware = "ovmf | uefi | bios | seabios | rombios | pvgrub"
>>
>> What is the purpose of having uefi and bios in there?  ovmf is the uefi
>> implementation, and {rom,sea}bios are the bios implementations.
>>
>> How does someone specify ovmf + seabios as a CSM?
> 
> Hm, I have no idea. How is this done usually, is ovmf built with
> seabios support, or is it fetched by ovmf from the uefi partition?
> 
>>> This allows to load a firmware inside of the guest and run it in guest
>>> mode. Note that the firmware needs to support booting in PVH mode.
>>>
>>> There's no plan to support any bios or pvgrub ATM for PVH, those
>>> options are simply listed for completeness. Also, generic options like
>>> uefi or bios would be aliases to a concrete implementation by the
>>> toolstack, ie: uefi -> ovmf, bios -> seabios most likely.
>>
>> Oh - here is the reason.  -1 to this idea.  We don't want to explicitly
>> let people choose options which are liable to change under their feet if
>> they were to boot the same .cfg file on a newer version of Xen, as their
>> VM will inevitable break.
> 
> Noted, I think not allowing bios or uefi is fine, I would rather
> document in the man page that our recommended bios implementation is
> seabios and the uefi one ovmf.

We need both "I don't care much just choose the best one" options, and
"I want this specific version and not have it change" options.

You accurately describe the problem with having *only* "This is the
general idea but the implementation can change under my feet" options.
But there's also a problem with having only "I want this specific
version" options: Namely, that a lot of people really don't care much
and want the most reasonably up-to-date version, and don't want to know
the details below.

Having both allows us to be reasonably user-friendly to both "just make
it work" people and people who want to "get their hands greasy" knowing
all the technical inner workings.


>> Where does hvmloader fit into this mix?
> 
> Right, I wasn't planning anyone using hvmloader, but there's no reason
> to prevent it. I guess it would fit into the "firmware" option, but
> then you should be able to use something like: firmware = "hvmloader +
> ovmf".
> 
> What would be the purpose of using hvmloader inside of a PVH guest?
> Hardware initialization?

AFAICT hvmloader is an internal implementation detail; the user should,
in general, not need to know anything about it (except in cases like
XTF, where you're deliberately abusing the system).

And as Roger said, the `firmware=` option should allow a user to specify
their own binary.

>> Instead of kernel= and ramdisk=, it would be better to generalise to
>> something like modules=[...], perhaps with kernel being an alias for
>> module[0] etc.  hvmloader already takes multiple binaries using the PVH
>> module system, and PV guests are perfectly capable of multiple modules
>> as well.  One specific example where an extra module would be very
>> helpful is for providing the cloudinit install config file.
> 
> I might prefer to keep the current kernel = "..." and convert ramdisk
> into a list named modules. Do you think (this also applies to xl/libxl
> maintainers) we coul

Re: [Xen-devel] [PATCH 1/6] xen-blkfront: quiesce/unquiesce queue instead of start/stop queues

On Sat, Jul 15, 2017 at 07:15:56AM +0800, Ming Lei wrote:
> stopping queue may cause race and may not stop the queue really
> after the API returns, and we have improved quiescing
> interface and it really can block dispatching once it returns.
> 
> So switch to quiesce/unquiece like what we did on other drivers
> (NVMe, NBD, mtip32xx, ...)
> 
> The blk_mq_stop_hw_queues() and blk_mq_start_stopped_hw_queues()
> used in blkif_queue_rq() and blkif_interrupt() are for congestion
> control, we leave it as it is since it is safe for this usage.

Again I yet don't understand the difference between those two, neither
why start/stop is not fixed instead of introducing quiesce/unquiece.
Not to mention that start/stop is not documented, which makes all this
even more fun.

Anyway I would like to ask, is the way to re-start a stopped queue the
same way to unquiece?

If not I would rather prefer that start/stop or quiece/unquiece is
used exclusively, in order to not make the code even more complex. It
seems fairly easy to mess up and call "start" on a "quiesced" queue
(or the other way around).

Roger.

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

Re: [Xen-devel] Notes on stubdoms and latency on ARM

On 07/17/2017 11:04 AM, Julien Grall wrote:
> Hi,
> 
> On 17/07/17 10:25, George Dunlap wrote:
>> On 07/12/2017 07:14 AM, Dario Faggioli wrote:
>>> On Fri, 2017-07-07 at 14:12 -0700, Stefano Stabellini wrote:
 On Fri, 7 Jul 2017, Volodymyr Babchuk wrote:
>>>
>> Since you are using Credit, can you try to disable context switch
>> rate
>> limiting?
>
> Yep. You are right. In the environment described above (Case 2) I
> now
> get much better results:
>
>  real 1.85
> user 0.00
> sys 1.85

 From 113 to 1.85 -- WOW!

 Obviously I am no scheduler expert, but shouldn't we advertise a bit
 better a scheduler configuration option that makes things _one
 hundred
 times faster_ ?!

>>> So, to be fair, so far, we've bitten this hard by this only on
>>> artificially constructed test cases, where either some extreme
>>> assumption were made (e.g., that all the vCPUs except one always run at
>>> 100% load) or pinning was used in a weird and suboptimal way. And there
>>> are workload where it has been verified that it helps making
>>> performance better (poor SpecVIRT  results without it was the main
>>> motivation having it upstream, and on by default).
>>>
>>> That being said, I personally have never liked rate-limiting, it always
>>> looked to me like the wrong solution.
>>
>> In fact, I *think* the only reason it may have been introduced is that
>> there was a bug in the credit2 code at the time such that it always had
>> a single runqueue no matter what your actual pcpu topology was.
> 
> FWIW, we don't yet parse the pCPU topology on ARM. AFAIU, we always tell
> Xen each CPU is in its own core. Will it have some implications in the
> scheduler?

Just checking -- you do mean its own core, as opposed to its own socket?
 (Or NUMA node?)

On any system without hyperthreading (or with HT disabled), that's what
an x86 system will see as well.

Most schedulers have one runqueue per logical cpu.  Credit2 has the
option of having one runqueue per logical cpu, one per core (i.e.,
hyperthreads share a runqueue), one runqueue per socket (i.e., all cores
on the same socket share a runqueue), or one socket across the whole
system.  I *think* we made one socket per core the default a while back
to deal with multithreading, but I may not be remembering correctly.

In any case, if you don't have threads, then reporting each logical cpu
as its own core is the right thing to do.

If you're mis-reporting sockets, then the scheduler will be unable to
take that into account.  But that's not usually going to be a major
issue, mainly because the scheduler is not actually in a position to
determine, most of the time, which is the optimal configuration.  If two
vcpus are communicating a lot, then the optimal configuration is to put
them on different cores of the same socket (so they can share an L3
cache); if two vcpus are computing independently, then the optimal
configuration is to put them on different sockets, so they can each have
their own L3 cache.  Xen isn't in a position to know which one is more
important, so it just assumes each vcpu is independent.

All that to say: It shouldn't be a major issue if you are mis-reporting
sockets. :-)

 -George

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

Re: [Xen-devel] [PATCH] AMD IOMMU: drop amd_iommu_setup_hwdom_device()

On Fri, Jul 14, 2017 at 08:04:16AM -0600, Jan Beulich wrote:
> By moving its bridge special casing to amd_iommu_add_device(), we can
> pass the latter to setup_hwdom_pci_devices() and at once consistently
> handle bridges discovered at boot time as well as such reported by Dom0
> later on.
> 
> Signed-off-by: Jan Beulich 

Reviewed-by: Roger Pau Monné 

With one nit:

> @@ -490,15 +465,25 @@ static int amd_iommu_add_device(u8 devfn
>  {
>  struct amd_iommu *iommu;
>  u16 bdf;
> +
>  if ( !pdev->domain )
>  return -EINVAL;
>  
>  bdf = PCI_BDF2(pdev->bus, pdev->devfn);
>  iommu = find_iommu_for_device(pdev->seg, bdf);
> -if ( !iommu )
> +if ( unlikely(!iommu) )
>  {
> -AMD_IOMMU_DEBUG("Fail to find iommu."
> -" %04x:%02x:%02x.%u cannot be assigned to dom%d\n",
> +/* Filter bridge devices. */
> +if ( pdev->type == DEV_TYPE_PCI_HOST_BRIDGE &&
> + is_hardware_domain(pdev->domain) )
> +{
> +AMD_IOMMU_DEBUG("Skipping host bridge %04x:%02x:%02x.%u\n",
> +pdev->seg, PCI_BUS(bdf), PCI_SLOT(bdf),
> +PCI_FUNC(bdf));

Is there any reason to use bdf instead of pdev->bus and devfn? I'm
asking because that's done below, so I would rather use that for
coherency.

Roger.

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

[Xen-devel] ARM: Adjusting guest memory size through xl mem-{set|max} fails

2017-07-17 Thread Sergej Proskurin

Hi all,

My setup comprises an ARMv7 (Arndale, Linux kernel v4.11.6) and an ARMv8
(LeMaker HiKey, Linux kernel v4.9.0) development board. On both boards,
I have Xen version 4.10-unstable running with the associated tools to
manage a domu.

Currently, I am trying to get xl mem-{set|max} to work on both
architectures. Unfortunately, both command invocations fail with the
following message (I remember using xl mem-{set|max} on ARMv7 before
with Xen version 4.7 and 4.8):

---
xl: libxl.c:339: libxl_defbool_val: Assertion
`!libxl_defbool_is_default(db)' failed.
Aborted
---

The domu is created with the following parameters:

---
kernel= "/boot/zImage"
name = "domu"
memory = 512
vcpus = 2
disk=[ 'phy:/dev/vg0/VG0, xvda,w' ]
extra = 'console=hvc0 xencons=tty root=/dev/xvda rw'
---

My Kernel versions have CONFIG_XEN_BALLOON flag set (see ARMv7 example
Linux .config below).

---
$ cat .config | grep -i XEN
CONFIG_XEN_DOM0=y
CONFIG_XEN=y
CONFIG_XEN_BLKDEV_FRONTEND=y
CONFIG_XEN_BLKDEV_BACKEND=y
# CONFIG_XEN_SCSI_FRONTEND is not set
CONFIG_XEN_NETDEV_FRONTEND=y
CONFIG_XEN_NETDEV_BACKEND=y
CONFIG_INPUT_XEN_KBDDEV_FRONTEND=y
CONFIG_HVC_XEN=y
CONFIG_HVC_XEN_FRONTEND=y
# CONFIG_TCG_XEN is not set
# CONFIG_XEN_WDT is not set
CONFIG_XEN_FBDEV_FRONTEND=y
# Xen driver support
CONFIG_XEN_BALLOON=y
CONFIG_XEN_SCRUB_PAGES=y
CONFIG_XEN_DEV_EVTCHN=y
CONFIG_XEN_BACKEND=y
CONFIG_XENFS=y
CONFIG_XEN_COMPAT_XENFS=y
CONFIG_XEN_SYS_HYPERVISOR=y
CONFIG_XEN_XENBUS_FRONTEND=y
CONFIG_XEN_GNTDEV=m
CONFIG_XEN_GRANT_DEV_ALLOC=m
CONFIG_SWIOTLB_XEN=y
CONFIG_XEN_PRIVCMD=y
CONFIG_XEN_AUTO_XLATE=y
---

Besides, I can see in the dmesg output that the balloon driver gets
initialized:

---
# dmesg | grep -i balloon
[0.180942] xen:balloon: Initialising balloon driver
[0.187103] xen_balloon: Initialising balloon driver
---

It would be great if someone would help me to resolve this issue as I am
obviously missing something. Thank you very much in advance.

Best regards,
~Sergej


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

[Xen-devel] [PATCH RFC] tools: Drop xc_cpuid_check() and bindings

There are no current users which I can locate.  One piece of xend which didn't
move forwards into xl/libxl is this:

  #   Configure host CPUID consistency checks, which must be satisfied for this
  #   VM to be allowed to run on this host's processor type:
  #cpuid_check=[ '1:ecx=xx1x' ]
  # - Host must have VMX feature flag set

The implementation of xc_cpuid_check() is conceptually broken.  Dom0's view of
CPUID is not the approprite view to check, and will be wrong in the presence
of CPUID masking/faulting, and for HVM-based toolstack domains.

If it turns out that the functionality is required, it should be implemented
in terms of XEN_SYSCTL_get_cpuid_policy to use the proper CPUID view.

Signed-off-by: Andrew Cooper 
---
CC: Ian Jackson 
CC: Wei Liu 
CC: Marek Marczykowski-Górecki 
CC: David Scott 
CC: Christian Lindig 
CC: Juergen Gross 
CC: Jim Fehlig 
CC: Boris Ostrovsky 
CC: Konrad Rzeszutek Wilk 

RFC initially for feedback, and to see if anyone does expect to be using this
call.  It turns out that Xapi has a library function using it, but that
function is dead so can be removed.
---
 tools/libxc/include/xenctrl.h   |  4 ---
 tools/libxc/xc_cpuid_x86.c  | 57 -
 tools/ocaml/libs/xc/xenctrl.ml  |  2 --
 tools/ocaml/libs/xc/xenctrl.mli |  3 --
 tools/ocaml/libs/xc/xenctrl_stubs.c | 43 
 tools/python/xen/lowlevel/xc/xc.c   | 34 --
 6 files changed, 143 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 96df836..acd778c 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1793,10 +1793,6 @@ int xc_domain_debug_control(xc_interface *xch,
 uint32_t vcpu);
 
 #if defined(__i386__) || defined(__x86_64__)
-int xc_cpuid_check(xc_interface *xch,
-   const unsigned int *input,
-   const char **config,
-   char **config_transformed);
 int xc_cpuid_set(xc_interface *xch,
  domid_t domid,
  const unsigned int *input,
diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c
index 6f82277..d1d0b51 100644
--- a/tools/libxc/xc_cpuid_x86.c
+++ b/tools/libxc/xc_cpuid_x86.c
@@ -855,63 +855,6 @@ int xc_cpuid_apply_policy(xc_interface *xch, domid_t domid,
 }
 
 /*
- * Check whether a VM is allowed to launch on this host's processor type.
- *
- * @config format is similar to that of xc_cpuid_set():
- *  '1' -> the bit must be set to 1
- *  '0' -> must be 0
- *  'x' -> we don't care
- *  's' -> (same) must be the same
- */
-int xc_cpuid_check(
-xc_interface *xch, const unsigned int *input,
-const char **config,
-char **config_transformed)
-{
-int i, j, rc;
-unsigned int regs[4];
-
-memset(config_transformed, 0, 4 * sizeof(*config_transformed));
-
-cpuid(input, regs);
-
-for ( i = 0; i < 4; i++ )
-{
-if ( config[i] == NULL )
-continue;
-config_transformed[i] = alloc_str();
-if ( config_transformed[i] == NULL )
-{
-rc = -ENOMEM;
-goto fail_rc;
-}
-for ( j = 0; j < 32; j++ )
-{
-unsigned char val = !!((regs[i] & (1U << (31 - j;
-if ( !strchr("10xs", config[i][j]) ||
- ((config[i][j] == '1') && !val) ||
- ((config[i][j] == '0') && val) )
-goto fail;
-config_transformed[i][j] = config[i][j];
-if ( config[i][j] == 's' )
-config_transformed[i][j] = '0' + val;
-}
-}
-
-return 0;
-
- fail:
-rc = -EPERM;
- fail_rc:
-for ( i = 0; i < 4; i++ )
-{
-free(config_transformed[i]);
-config_transformed[i] = NULL;
-}
-return rc;
-}
-
-/*
  * Configure a single input with the informatiom from config.
  *
  * Config is an array of strings:
diff --git a/tools/ocaml/libs/xc/xenctrl.ml b/tools/ocaml/libs/xc/xenctrl.ml
index 75006e7..70a325b 100644
--- a/tools/ocaml/libs/xc/xenctrl.ml
+++ b/tools/ocaml/libs/xc/xenctrl.ml
@@ -218,8 +218,6 @@ external domain_cpuid_set: handle -> domid -> (int64 * 
(int64 option))
= "stub_xc_domain_cpuid_set"
 external domain_cpuid_apply_policy: handle -> domid -> unit
= "stub_xc_domain_cpuid_apply_policy"
-external cpuid_check: handle -> (int64 * (int64 option)) -> string option 
array -> (bool * string option array)
-   = "stub_xc_cpuid_check"
 
 external map_foreign_range: handle -> domid -> int
  -> nativeint -> Xenmmap.mmap_interface
diff --git a/tools/ocaml/libs/xc/xenctrl.mli b/tools/ocaml/libs/xc/xenctrl.mli
index 720e4b2..702d8a7 100644
--- a/tools/ocaml/libs/xc/xenctrl.mli
+++ b/tools/ocaml/libs/xc/xenctrl.mli
@@ -179,6 +179,3 @@ external domain_cpuid_set: handle -> domid -> (int64 * 
(int64 option))
= "stub_xc_domain_cpuid_set"
 external domain_c

[Xen-devel] [XenSummit 2017] Build tools follow up

2017-07-17 Thread Oleksandr Andrushchenko


Hi, all!

This is a follow-up on Xen distribution build systems we saw at the
summit and invitation for sharing thoughts and ways we build our images and
distros. I would like to specifically ask OpenXT project to reply with the
description of their build system so we have clear picture of what is being
developed and used around. And of course if there are other approaches 
to do the

same you are welcome to share those as well.

On our side at EPAM we have developed a distribution which is called 
xt-distro

(xt stays for Xen troops [0]) with the following goals in mind:
1. Make it possible to easily build different images as a single 
distribution

   - Separate images for different domains should be combined into a
 distribution, e.g. set of images/artifacts required to run them as a
 system
   - Xt-distro allows doing so as easy as running bitbake with the 
predefined

 target, e.g. “bitbake xt-image”
2. Easily deal with different BSPs for different platforms using a 
unified way

   with little or no EPAM specific code/scripts
   - We use bitbake and stripped version of Poky/meta-openembedded, so 
there are
 little in-house extensions we added to deal with Yocto based BSPs 
[1], [2]
   - We use bitbake’s well defined scripting language [3], so no yet 
another

 language to learn
   - We use Google repo tool to maintain sets of meta layers as 
manifest files [4]

3. Ability to easily collect component revisions, so any build can be
   reproduced if need be
   - We save commit IDs of every component of the build including 
versions of the

 meta layers
4. Ability to easily customize and tune builds, e.g. URIs, 
versions/commitIDs,

   branches used
   - This is purely done in bitbake’s recipe language
5. Make patching process easy
   - With our extensions you can use bblayers.conf, local.conf, patches 
which

 are part of a meta layer which is usually a manual step
6. Code reuse is a must, e.g. the same set of software must be easily 
built for
   different platforms without copying build scripts of the existing 
components
   - With bitbake’s meta layers we define generic recipes, e.g. 
suitable for all

 platforms [5] (think of it as a library) and tuning meta layers [6]
 (we use product concept here) which define specific 
versions/revisions of the

 components, apply specific patches and add/remove software
7. Cross compilation must be an easy task to do
   - This is easily achieved with Yocto builds and usually not a 
problem for other

 build systems as well (with SDKs)
   - Allows building for x86/ARM and other architectures as well
8. There must be a simple way to share build artifacts of different 
domains between
   each other, for example, DomU’s kernel should be a part of Dom0’s 
rootfs, so

   xl/libxl can access it
   - This is achieved with bitbake’s recipes, so no EPAM extensions
9. Possibility to easily use different build systems for different 
components of

   the system.
   - Bitbake allows you building makefile based projects, CMake etc. 
out of the box,

 so adding firmware, stubdoms made easy
10. Development support
   - We use SDKs built by bitbake so during everyday development you 
are packed with
 all that is needed to re-create build environment (with both host 
and target

 environments, e.g. x86 host tools and ARM cross-compiler)
   - Speed up builds for developers within organization, e.g. we reuse 
downloads and

 build cache between all of the developer’s machines on our network
11. Make the build system suitable for build automation
- We have created a python script which can easily be used with
  Jenkins or even cron [7]

For example, with xt-distro our development product delivers: Xen image and
policy file, Dom0 kernel and dtb images (Dom0 + DomU), Dom0 rootfs image 
(with

embedded kernels and configuration for DomU), DomU rootfs image. This
effectively means, that the build system can provide you with the 
complete set

of images to run your product/distribution.

We are looking forward for any kind of feedback and will be glad to 
collaborate

on the above.

Thank you,
Xen-troops at EPAM

[0] https://github.com/xen-troops/xt-distro
[1] https://git.yoctoproject.org/cgit/cgit.cgi/poky
[2] http://cgit.openembedded.org/meta-openembedded
[3] 
http://www.yoctoproject.org/docs/2.3/bitbake-user-manual/bitbake-user-manual.html

[4] https://gerrit.googlesource.com/git-repo
[5] https://github.com/xen-troops/meta-xt-images
[6] https://github.com/xen-troops/meta-xt-prod-devel
[7] https://github.com/xen-troops/build-scripts


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

[Xen-devel] [PATCH 05/25 v6] xen/arm: vpl011: Rearrange xen header includes in alphabetical order in domctl.c

Rearrange xen header includes in alphabetical order in domctl.c.

Signed-off-by: Bhupinder Thakur 
Reviewed-by: Stefano Stabellini 
---
CC: Stefano Stabellini 
CC: Julien Grall 

Changes since v5:
- Corrected include of  in alphabetical order.

 xen/arch/arm/domctl.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c
index 971caec..db6838d 100644
--- a/xen/arch/arm/domctl.c
+++ b/xen/arch/arm/domctl.c
@@ -4,12 +4,12 @@
  * Copyright (c) 2012, Citrix Systems
  */
 
-#include 
-#include 
 #include 
-#include 
 #include 
 #include 
+#include 
+#include 
+#include 
 #include 
 #include 
 
-- 
2.7.4


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

[Xen-devel] [PATCH 02/25 v6] xen/arm: vpl011: Add SBSA UART emulation in Xen

Add emulation code to emulate read/write access to pl011 registers
and pl011 interrupts:

- Emulate DR read/write by reading and writing from/to the IN
  and OUT ring buffers and raising an event to the backend when
  there is data in the OUT ring buffer and injecting an interrupt
  to the guest when there is data in the IN ring buffer

- Other registers are related to interrupt management and
  essentially control when interrupts are delivered to the guest

This patch implements the SBSA Generic UART which is a subset of ARM
PL011 UART.

The SBSA Generic UART is covered in Appendix B of
https://static.docs.arm.com/den0029/a/Server_Base_System_Architecture_v3_1_ARM_DEN_0029A.pdf

Signed-off-by: Bhupinder Thakur 
---
CC: Stefano Stabellini 
CC: Julien Grall 
CC: Andre Przywara 

Changes since v5:
- use  instead of  for including arm specific header files.
- renamed shadow_uartris to shadow_uartmis to indicate that it is masked 
interrupt status.
- use smp_mb() instead of smp_rmb() in vpl011_write_data().

Changes since v4:
- Renamed vpl011_update() to vpl011_update_interrupt_status() and added logic 
to avoid
  raising spurious interrupts.
- Used barrier instructions correctly while reading/writing data to the ring 
buffer.
- Proper lock taken before reading ring buffer indices.

Changes since v3:
- Moved the call to DEFINE_XEN_FLEX_RING from vpl011.h to public/console.h. 
This macro defines
  standard functions to operate on the ring buffer.
- Lock taken while updating the interrupt mask and clear registers in 
mmio_write.
- Use gfn_t instead of xen_pfn_t.
- vgic_free_virq called if there is any error in vpl011 initialization.
- mmio handlers freed if there is any error in vpl011 initialization.
- Removed vpl011->initialized flag usage as the same check could be done 
  using vpl011->ring-ref.
- Used return instead of break in the switch handling of emulation of different 
pl011 registers.
- Renamed vpl011_update_spi() to vpl011_update().

Changes since v2:
- Use generic vreg_reg* for read/write of registers emulating pl011.
- Use generic ring buffer functions defined using DEFINE_XEN_FLEX_RING.
- Renamed the SPI injection function to vpl011_update_spi() to reflect level 
  triggered nature of pl011 interrupts.
- The pl011 register access address should always be the base address of the
  corresponding register as per section B of the SBSA document. For this reason,
  the register range address access is not allowed.

Changes since v1:
- Removed the optimiztion related to sendiing events to xenconsole 
- Use local variables as ring buffer indices while using the ring buffer

 xen/arch/arm/Kconfig |   7 +
 xen/arch/arm/Makefile|   1 +
 xen/arch/arm/vpl011.c| 455 +++
 xen/include/asm-arm/domain.h |   6 +
 xen/include/asm-arm/pl011-uart.h |   2 +
 xen/include/asm-arm/vpl011.h |  72 +++
 xen/include/public/arch-arm.h|   6 +
 7 files changed, 549 insertions(+)
 create mode 100644 xen/arch/arm/vpl011.c
 create mode 100644 xen/include/asm-arm/vpl011.h

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index d46b98c..f58019d 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -50,6 +50,13 @@ config HAS_ITS
 prompt "GICv3 ITS MSI controller support" if EXPERT = "y"
 depends on HAS_GICV3
 
+config SBSA_VUART_CONSOLE
+   bool "Emulated SBSA UART console support"
+   default y
+   ---help---
+ Allows a guest to use SBSA Generic UART as a console. The
+ SBSA Generic UART implements a subset of ARM PL011 UART.
+
 endmenu
 
 menu "ARM errata workaround via the alternative framework"
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 49e1fb2..d9c6ebf 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -50,6 +50,7 @@ obj-$(CONFIG_HAS_GICV3) += vgic-v3.o
 obj-$(CONFIG_HAS_ITS) += vgic-v3-its.o
 obj-y += vm_event.o
 obj-y += vtimer.o
+obj-$(CONFIG_SBSA_VUART_CONSOLE) += vpl011.o
 obj-y += vpsci.o
 obj-y += vuart.o
 
diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
new file mode 100644
index 000..dc98490
--- /dev/null
+++ b/xen/arch/arm/vpl011.c
@@ -0,0 +1,455 @@
+/*
+ * arch/arm/vpl011.c
+ *
+ * Virtual PL011 UART
+ *
+ * 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 .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include

[Xen-devel] [PATCH 03/25 v6] xen/arm: vpl011: Allocate a new GFN in the toolstack for vuart

Allocate a new gfn to be used as a ring buffer between xenconsole
and Xen for sending/receiving pl011 console data.

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

Changes since v4:
- Removed xc_get_vuart_gfn() as it is not required since the vpl011 
initialization
  function which used this API has been moved to after gfn is allocated.
- I have included the reviewed-by and acked-by tags as there is no change in the
  logic.

Changes since v3:
- Added a new helper function xc_get_vuart_gfn() to return the GFN allocated for
  vpl011.
- Since a new function has been added in this patch, I have not included 
Stefano's
  reviewed-by and Wei's acked-by tags.

Changes since v2:
- Removed the DOMCTL call to set the GFN as now this information is passed
  in the DOMCTL call to initialize vpl011 emulation.

 tools/libxc/include/xc_dom.h | 2 ++
 tools/libxc/xc_dom_arm.c | 5 -
 tools/libxc/xc_dom_boot.c| 2 ++
 3 files changed, 8 insertions(+), 1 deletion(-)

 tools/libxc/include/xc_dom.h | 2 ++
 tools/libxc/xc_dom_arm.c | 5 -
 tools/libxc/xc_dom_boot.c| 2 ++
 3 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index ce47058..6e06ef1 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -216,6 +216,8 @@ struct xc_dom_image {
 
 /* Extra SMBIOS structures passed to HVMLOADER */
 struct xc_hvm_firmware_module smbios_module;
+
+xen_pfn_t vuart_gfn;
 };
 
 /* --- pluggable kernel loader - */
diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
index e7d4bd0..c981b7a 100644
--- a/tools/libxc/xc_dom_arm.c
+++ b/tools/libxc/xc_dom_arm.c
@@ -26,10 +26,11 @@
 #include "xg_private.h"
 #include "xc_dom.h"
 
-#define NR_MAGIC_PAGES 3
+#define NR_MAGIC_PAGES 4
 #define CONSOLE_PFN_OFFSET 0
 #define XENSTORE_PFN_OFFSET 1
 #define MEMACCESS_PFN_OFFSET 2
+#define VUART_PFN_OFFSET 3
 
 #define LPAE_SHIFT 9
 
@@ -85,10 +86,12 @@ static int alloc_magic_pages(struct xc_dom_image *dom)
 
 dom->console_pfn = base + CONSOLE_PFN_OFFSET;
 dom->xenstore_pfn = base + XENSTORE_PFN_OFFSET;
+dom->vuart_gfn = base + VUART_PFN_OFFSET;
 
 xc_clear_domain_page(dom->xch, dom->guest_domid, dom->console_pfn);
 xc_clear_domain_page(dom->xch, dom->guest_domid, dom->xenstore_pfn);
 xc_clear_domain_page(dom->xch, dom->guest_domid, base + 
MEMACCESS_PFN_OFFSET);
+xc_clear_domain_page(dom->xch, dom->guest_domid, base + VUART_PFN_OFFSET);
 xc_hvm_param_set(dom->xch, dom->guest_domid, HVM_PARAM_CONSOLE_PFN,
 dom->console_pfn);
 xc_hvm_param_set(dom->xch, dom->guest_domid, HVM_PARAM_STORE_PFN,
diff --git a/tools/libxc/xc_dom_boot.c b/tools/libxc/xc_dom_boot.c
index c3b44dd..8a376d0 100644
--- a/tools/libxc/xc_dom_boot.c
+++ b/tools/libxc/xc_dom_boot.c
@@ -226,6 +226,8 @@ int xc_dom_boot_image(struct xc_dom_image *dom)
 return rc;
 if ( (rc = clear_page(dom, dom->xenstore_pfn)) != 0 )
 return rc;
+if ( (rc = clear_page(dom, dom->vuart_gfn)) != 0 )
+return rc;
 
 /* start info page */
 if ( dom->arch_hooks->start_info )
-- 
2.7.4


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

[Xen-devel] [PATCH 04/25 v6] xen/arm: vpl011: Add support for vuart in libxl

An option is provided in libxl to enable/disable sbsa vuart while
creating a guest domain.

Libxl now suppots a generic vuart console and sbsa uart is a specific type.
In future support can be added for multiple vuart of different types.

User can enable sbsa vuart by adding the following line in the guest
configuration file:

vuart = "sbsa_uart"

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

Changes since v4:
- Renamed "pl011" to "sbsa_uart".

Changes since v3:
- Added a new config option CONFIG_VUART_CONSOLE to enable/disable vuart console
  support.
- Moved libxl_vuart_type to arch-arm part of libxl_domain_build_info
- Updated xl command help to mention new console type - vuart.

Changes since v2:
- Defined vuart option as an enum instead of a string.
- Removed the domain creation flag defined for vuart and the related code
  to pass on the information while domain creation. Now vpl011 is initialized
  independent of domain creation through new DOMCTL APIs.

 tools/libxl/libxl.h  | 6 ++
 tools/libxl/libxl_console.c  | 3 +++
 tools/libxl/libxl_dom.c  | 1 +
 tools/libxl/libxl_internal.h | 3 +++
 tools/libxl/libxl_types.idl  | 7 +++
 tools/xl/xl_cmdtable.c   | 2 +-
 tools/xl/xl_console.c| 5 -
 tools/xl/xl_parse.c  | 8 
 8 files changed, 33 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 7cf0f31..892ed35 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -306,6 +306,12 @@
 #define LIBXL_HAVE_BUILDINFO_HVM_ACPI_LAPTOP_SLATE 1
 
 /*
+ * LIBXL_HAVE_VUART indicates that xenconsole/client supports
+ * virtual uart.
+ */
+#define LIBXL_HAVE_VUART 1
+
+/*
  * libxl ABI compatibility
  *
  * The only guarantee which libxl makes regarding ABI compatibility
diff --git a/tools/libxl/libxl_console.c b/tools/libxl/libxl_console.c
index 446e766..853be15 100644
--- a/tools/libxl/libxl_console.c
+++ b/tools/libxl/libxl_console.c
@@ -67,6 +67,9 @@ int libxl_console_exec(libxl_ctx *ctx, uint32_t domid, int 
cons_num,
 case LIBXL_CONSOLE_TYPE_SERIAL:
 cons_type_s = "serial";
 break;
+case LIBXL_CONSOLE_TYPE_VUART:
+cons_type_s = "vuart";
+break;
 default:
 goto out;
 }
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index f54fd49..e0f0d78 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -803,6 +803,7 @@ int libxl__build_pv(libxl__gc *gc, uint32_t domid,
 if (xc_dom_translated(dom)) {
 state->console_mfn = dom->console_pfn;
 state->store_mfn = dom->xenstore_pfn;
+state->vuart_gfn = dom->vuart_gfn;
 } else {
 state->console_mfn = xc_dom_p2m(dom, dom->console_pfn);
 state->store_mfn = xc_dom_p2m(dom, dom->xenstore_pfn);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index afe6652..d0d50c3 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1139,6 +1139,9 @@ typedef struct {
 uint32_t num_vmemranges;
 
 xc_domain_configuration_t config;
+
+xen_pfn_t vuart_gfn;
+evtchn_port_t vuart_port;
 } libxl__domain_build_state;
 
 _hidden int libxl__build_pre(libxl__gc *gc, uint32_t domid,
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 8a9849c..728cc56 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -105,6 +105,7 @@ libxl_console_type = Enumeration("console_type", [
 (0, "UNKNOWN"),
 (1, "SERIAL"),
 (2, "PV"),
+(3, "VUART"),
 ])
 
 libxl_disk_format = Enumeration("disk_format", [
@@ -240,6 +241,11 @@ libxl_checkpointed_stream = 
Enumeration("checkpointed_stream", [
 (2, "COLO"),
 ])
 
+libxl_vuart_type = Enumeration("vuart_type", [
+(0, "unknown"),
+(1, "sbsa_uart"),
+])
+
 #
 # Complex libxl types
 #
@@ -581,6 +587,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
 
 
 ("arch_arm", Struct(None, [("gic_version", libxl_gic_version),
+   ("vuart", libxl_vuart_type),
   ])),
 # Alternate p2m is not bound to any architecture or guest type, as it is
 # supported by x86 HVM and ARM support is planned.
diff --git a/tools/xl/xl_cmdtable.c b/tools/xl/xl_cmdtable.c
index 30eb93c..9f91651 100644
--- a/tools/xl/xl_cmdtable.c
+++ b/tools/xl/xl_cmdtable.c
@@ -133,7 +133,7 @@ struct cmd_spec cmd_table[] = {
   &main_console, 0, 0,
   "Attach to domain's console",
   "[options] \n"
-  "-tconsole type, pv or serial\n"
+  "-tconsole type, pv , serial or vuart\n"
   "-n  console number"
 },
 { "vncviewer",
diff --git a/tools/xl/xl_console.c b/tools/xl/xl_console.c
index 0508dda..4e65d73 100644
--- a/tools/xl/xl_console.c
+++ b/tools/xl/xl_console.c
@@ -27,6 +27,7 @@ int main_console(int argc, char **argv)
 u

[Xen-devel] [PATCH 09/25 v6] xen/arm: vpl011: Rename the console structure field conspath to xspath

The console->conspath name is changed to console->xspath as it is
clear from the name that it is referring to xenstore path.

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

Changes since v4:
- Split this change in a separate patch.

 tools/console/daemon/io.c | 30 +++---
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/tools/console/daemon/io.c b/tools/console/daemon/io.c
index 30cd167..6f5c69c 100644
--- a/tools/console/daemon/io.c
+++ b/tools/console/daemon/io.c
@@ -95,7 +95,7 @@ struct console {
int slave_fd;
int log_fd;
struct buffer buffer;
-   char *conspath;
+   char *xspath;
int ring_ref;
xenevtchn_handle *xce_handle;
int xce_pollfd_idx;
@@ -463,7 +463,7 @@ static int domain_create_tty(struct domain *dom)
goto out;
}
 
-   success = asprintf(&path, "%s/limit", con->conspath) !=
+   success = asprintf(&path, "%s/limit", con->xspath) !=
-1;
if (!success)
goto out;
@@ -474,7 +474,7 @@ static int domain_create_tty(struct domain *dom)
}
free(path);
 
-   success = (asprintf(&path, "%s/tty", con->conspath) != -1);
+   success = (asprintf(&path, "%s/tty", con->xspath) != -1);
if (!success)
goto out;
success = xs_write(xs, XBT_NULL, path, slave, strlen(slave));
@@ -546,14 +546,14 @@ static int domain_create_ring(struct domain *dom)
char *type, path[PATH_MAX];
struct console *con = &dom->console;
 
-   err = xs_gather(xs, con->conspath,
+   err = xs_gather(xs, con->xspath,
"ring-ref", "%u", &ring_ref,
"port", "%i", &remote_port,
NULL);
if (err)
goto out;
 
-   snprintf(path, sizeof(path), "%s/type", con->conspath);
+   snprintf(path, sizeof(path), "%s/type", con->xspath);
type = xs_read(xs, XBT_NULL, path, NULL);
if (type && strcmp(type, "xenconsoled") != 0) {
free(type);
@@ -646,13 +646,13 @@ static bool watch_domain(struct domain *dom, bool watch)
 
snprintf(domid_str, sizeof(domid_str), "dom%u", dom->domid);
if (watch) {
-   success = xs_watch(xs, con->conspath, domid_str);
+   success = xs_watch(xs, con->xspath, domid_str);
if (success)
domain_create_ring(dom);
else
-   xs_unwatch(xs, con->conspath, domid_str);
+   xs_unwatch(xs, con->xspath, domid_str);
} else {
-   success = xs_unwatch(xs, con->conspath, domid_str);
+   success = xs_unwatch(xs, con->xspath, domid_str);
}
 
return success;
@@ -682,13 +682,13 @@ static struct domain *create_domain(int domid)
dom->domid = domid;
 
con = &dom->console;
-   con->conspath = xs_get_domain_path(xs, dom->domid);
-   s = realloc(con->conspath, strlen(con->conspath) +
+   con->xspath = xs_get_domain_path(xs, dom->domid);
+   s = realloc(con->xspath, strlen(con->xspath) +
strlen("/console") + 1);
if (s == NULL)
goto out;
-   con->conspath = s;
-   strcat(con->conspath, "/console");
+   con->xspath = s;
+   strcat(con->xspath, "/console");
 
con->master_fd = -1;
con->master_pollfd_idx = -1;
@@ -712,7 +712,7 @@ static struct domain *create_domain(int domid)
 
return dom;
  out:
-   free(con->conspath);
+   free(con->xspath);
free(dom);
return NULL;
 }
@@ -756,8 +756,8 @@ static void cleanup_domain(struct domain *d)
free(con->buffer.data);
con->buffer.data = NULL;
 
-   free(con->conspath);
-   con->conspath = NULL;
+   free(con->xspath);
+   con->xspath = NULL;
 
remove_domain(d);
 }
-- 
2.7.4


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

[Xen-devel] [PATCH 07/25 v6] xen/arm: vpl011: Add a new vuart node in the xenstore

Add a new vuart console node to xenstore. This node is added at

/local/domain/$DOMID/vuart/0.

The node contains information such as the ring-ref, event channel,
buffer limit and type of console.

Xenconsole reads the node information to setup the ring buffer and
event channel for sending/receiving vuart data.

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

Changes since v4:
-  vuart_device moved inside libxl__device_vuart_add() as a local variable.

Changes since v3:
- Added a backend node for vpl011.
- Removed libxl__device_vuart_add() for HVM guest. It is called only for PV 
guest.

 tools/libxl/libxl_console.c  | 44 
 tools/libxl/libxl_create.c   |  9 +++-
 tools/libxl/libxl_device.c   |  9 ++--
 tools/libxl/libxl_internal.h |  3 +++
 tools/libxl/libxl_types_internal.idl |  1 +
 5 files changed, 63 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/libxl_console.c b/tools/libxl/libxl_console.c
index 853be15..cdaf7fd 100644
--- a/tools/libxl/libxl_console.c
+++ b/tools/libxl/libxl_console.c
@@ -344,6 +344,50 @@ out:
 return rc;
 }
 
+int libxl__device_vuart_add(libxl__gc *gc, uint32_t domid,
+libxl__device_console *console,
+libxl__domain_build_state *state)
+{
+libxl__device device;
+flexarray_t *ro_front;
+flexarray_t *back;
+int rc;
+
+ro_front = flexarray_make(gc, 16, 1);
+back = flexarray_make(gc, 16, 1);
+
+device.backend_devid = console->devid;
+device.backend_domid = console->backend_domid;
+device.backend_kind = LIBXL__DEVICE_KIND_VUART;
+device.devid = console->devid;
+device.domid = domid;
+device.kind = LIBXL__DEVICE_KIND_VUART;
+
+flexarray_append(back, "frontend-id");
+flexarray_append(back, GCSPRINTF("%d", domid));
+flexarray_append(back, "online");
+flexarray_append(back, "1");
+flexarray_append(back, "state");
+flexarray_append(back, GCSPRINTF("%d", XenbusStateInitialising));
+flexarray_append(back, "protocol");
+flexarray_append(back, LIBXL_XENCONSOLE_PROTOCOL);
+
+flexarray_append(ro_front, "port");
+flexarray_append(ro_front, GCSPRINTF("%"PRIu32, state->vuart_port));
+flexarray_append(ro_front, "ring-ref");
+flexarray_append(ro_front, GCSPRINTF("%lu", state->vuart_gfn));
+flexarray_append(ro_front, "limit");
+flexarray_append(ro_front, GCSPRINTF("%d", LIBXL_XENCONSOLE_LIMIT));
+flexarray_append(ro_front, "type");
+flexarray_append(ro_front, "xenconsoled");
+
+rc = libxl__device_generic_add(gc, XBT_NULL, &device,
+   libxl__xs_kvs_of_flexarray(gc, back),
+   NULL,
+   libxl__xs_kvs_of_flexarray(gc, ro_front));
+return rc;
+}
+
 int libxl__init_console_from_channel(libxl__gc *gc,
  libxl__device_console *console,
  int dev_num,
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 1158303..54bc191 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -1367,7 +1367,7 @@ static void domcreate_launch_dm(libxl__egc *egc, 
libxl__multidev *multidev,
 }
 case LIBXL_DOMAIN_TYPE_PV:
 {
-libxl__device_console console;
+libxl__device_console console, vuart;
 libxl__device device;
 
 for (i = 0; i < d_config->num_vfbs; i++) {
@@ -1375,6 +1375,13 @@ static void domcreate_launch_dm(libxl__egc *egc, 
libxl__multidev *multidev,
 libxl__device_vkb_add(gc, domid, &d_config->vkbs[i]);
 }
 
+if (d_config->b_info.arch_arm.vuart) {
+init_console_info(gc, &vuart, 0);
+vuart.backend_domid = state->console_domid;
+libxl__device_vuart_add(gc, domid, &vuart, state);
+libxl__device_console_dispose(&vuart);
+}
+
 init_console_info(gc, &console, 0);
 console.backend_domid = state->console_domid;
 libxl__device_console_add(gc, domid, &console, state, &device);
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index 00356af..3b10c58 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -26,6 +26,9 @@ static char *libxl__device_frontend_path(libxl__gc *gc, 
libxl__device *device)
 if (device->kind == LIBXL__DEVICE_KIND_CONSOLE && device->devid == 0)
 return GCSPRINTF("%s/console", dom_path);
 
+if (device->kind == LIBXL__DEVICE_KIND_VUART)
+return GCSPRINTF("%s/vuart/%d", dom_path, device->devid);
+
 return GCSPRINTF("%s/device/%s/%d", dom_path,
  libxl__device_kind_to_string(device->kind),
  device->devid);
@@ -170,7 +173,8 @@ retry_transaction:
  * historically contained oth

[Xen-devel] [PATCH 01/25 v6] xen/arm: vpl011: Define common ring buffer helper functions in console.h

DEFINE_XEN_FLEX_RING(xencons) defines common helper functions such as
xencons_queued() to tell the current size of the ring buffer,
xencons_mask() to mask off the index, which are useful helper functions.
pl011 emulation code will use these helper functions.

io/console.h includes io/ring.h which defines DEFINE_XEN_FLEX_RING.

In console/daemon/io.c, string.h had to be included before io/console.h
because ring.h uses string functions.

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

Changes since v4:
- Split this change in a separate patch.

 tools/console/daemon/io.c   | 2 +-
 xen/include/public/io/console.h | 4 
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/tools/console/daemon/io.c b/tools/console/daemon/io.c
index 7e474bb..e8033d2 100644
--- a/tools/console/daemon/io.c
+++ b/tools/console/daemon/io.c
@@ -21,6 +21,7 @@
 
 #include "utils.h"
 #include "io.h"
+#include 
 #include 
 #include 
 #include 
@@ -29,7 +30,6 @@
 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/xen/include/public/io/console.h b/xen/include/public/io/console.h
index e2cd97f..5e45e1c 100644
--- a/xen/include/public/io/console.h
+++ b/xen/include/public/io/console.h
@@ -27,6 +27,8 @@
 #ifndef __XEN_PUBLIC_IO_CONSOLE_H__
 #define __XEN_PUBLIC_IO_CONSOLE_H__
 
+#include "ring.h"
+
 typedef uint32_t XENCONS_RING_IDX;
 
 #define MASK_XENCONS_IDX(idx, ring) ((idx) & (sizeof(ring)-1))
@@ -38,6 +40,8 @@ struct xencons_interface {
 XENCONS_RING_IDX out_cons, out_prod;
 };
 
+DEFINE_XEN_FLEX_RING(xencons);
+
 #endif /* __XEN_PUBLIC_IO_CONSOLE_H__ */
 
 /*
-- 
2.7.4


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

[Xen-devel] [PATCH 08/25 v6] xen/arm: vpl011: Modify xenconsole to define and use a new console structure

Xenconsole uses a domain structure which contains console specific fields. This
patch defines a new console structure, which would be used by the xenconsole
functions to perform console specific operations like reading/writing data 
from/to
the console ring buffer or reading/writing data from/to console tty.

This patch is in preparation to support multiple consoles to support vuart 
console.

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

Changes since v4:
- Moved the following fields from the struct domain to struct console:
  ->xenevtchn_handle *xce_handle;
  ->int xce_pollfd_idx;
  ->int event_count;
  ->long long next_period;

Changes since v3:
- The changes in xenconsole have been split into four patches. This is the 
first patch
  which modifies the xenconsole to use a new console structure.

Changes since v2:
- Defined a new function console_create_ring() which sets up the ring buffer 
and 
  event channel a new console. domain_create_ring() uses this function to setup
  a console.
- This patch does not contain vuart specific changes, which would be introduced 
in
  the next patch.
- Changes for keeping the PV log file name unchanged.

Changes since v1:
- Split the domain struture to a separate console structure
- Modified the functions to operate on the console struture
- Replaced repetitive per console code with generic code

 tools/console/daemon/io.c | 299 +-
 1 file changed, 165 insertions(+), 134 deletions(-)

diff --git a/tools/console/daemon/io.c b/tools/console/daemon/io.c
index e8033d2..30cd167 100644
--- a/tools/console/daemon/io.c
+++ b/tools/console/daemon/io.c
@@ -89,25 +89,30 @@ struct buffer {
size_t max_capacity;
 };
 
-struct domain {
-   int domid;
+struct console {
int master_fd;
int master_pollfd_idx;
int slave_fd;
int log_fd;
-   bool is_dead;
-   unsigned last_seen;
struct buffer buffer;
-   struct domain *next;
char *conspath;
int ring_ref;
-   xenevtchn_port_or_error_t local_port;
-   xenevtchn_port_or_error_t remote_port;
xenevtchn_handle *xce_handle;
int xce_pollfd_idx;
-   struct xencons_interface *interface;
int event_count;
long long next_period;
+   xenevtchn_port_or_error_t local_port;
+   xenevtchn_port_or_error_t remote_port;
+   struct xencons_interface *interface;
+   struct domain *d;
+};
+
+struct domain {
+   int domid;
+   bool is_dead;
+   unsigned last_seen;
+   struct domain *next;
+   struct console console;
 };
 
 static struct domain *dom_head;
@@ -160,9 +165,10 @@ static int write_with_timestamp(int fd, const char *data, 
size_t sz,
 
 static void buffer_append(struct domain *dom)
 {
-   struct buffer *buffer = &dom->buffer;
+   struct console *con = &dom->console;
+   struct buffer *buffer = &con->buffer;
XENCONS_RING_IDX cons, prod, size;
-   struct xencons_interface *intf = dom->interface;
+   struct xencons_interface *intf = con->interface;
 
cons = intf->out_cons;
prod = intf->out_prod;
@@ -187,22 +193,22 @@ static void buffer_append(struct domain *dom)
 
xen_mb();
intf->out_cons = cons;
-   xenevtchn_notify(dom->xce_handle, dom->local_port);
+   xenevtchn_notify(con->xce_handle, con->local_port);
 
/* Get the data to the logfile as early as possible because if
 * no one is listening on the console pty then it will fill up
 * and handle_tty_write will stop being called.
 */
-   if (dom->log_fd != -1) {
+   if (con->log_fd != -1) {
int logret;
if (log_time_guest) {
logret = write_with_timestamp(
-   dom->log_fd,
+   con->log_fd,
buffer->data + buffer->size - size,
size, &log_time_guest_needts);
} else {
logret = write_all(
-   dom->log_fd,
+   con->log_fd,
buffer->data + buffer->size - size,
size);
}
@@ -338,14 +344,16 @@ static int create_domain_log(struct domain *dom)
 
 static void domain_close_tty(struct domain *dom)
 {
-   if (dom->master_fd != -1) {
-   close(dom->master_fd);
-   dom->master_fd = -1;
+   struct console *con = &dom->console;
+
+   if (con->master_fd != -1) {
+   close(con->master_fd);
+   con->master_fd = -1;
}
 
-   if (dom->slave_fd != -1) {
-   close(dom->slave_fd);
-   dom->slave_fd = -1;
+   if (con->slave_fd != -1) {
+   close(con->slave_fd);
+

[Xen-devel] [PATCH 15/25 v6] xen/arm: vpl011: Add a new console_evtchn_unmask function in xenconsole

This patch introduces a new console_evtchn_unmask function. This function
unmasks the console event channel if it is masked for some timeout
period.

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

Changes since v5:
- Split this change in a separate patch.

 tools/console/daemon/io.c | 44 +++-
 1 file changed, 27 insertions(+), 17 deletions(-)

diff --git a/tools/console/daemon/io.c b/tools/console/daemon/io.c
index 6321d78..c272fe6 100644
--- a/tools/console/daemon/io.c
+++ b/tools/console/daemon/io.c
@@ -117,6 +117,11 @@ struct domain {
 
 static struct domain *dom_head;
 
+static inline bool console_enabled(struct console *con)
+{
+   return con->local_port != -1;
+}
+
 static int write_all(int fd, const char* buf, size_t len)
 {
while (len) {
@@ -909,6 +914,27 @@ static void handle_tty_write(struct console *con)
}
 }
 
+static void console_evtchn_unmask(struct console *con, void *data)
+{
+   long long now = (long long)data;
+
+   if (!console_enabled(con))
+   return;
+
+   /* CS 16257:955ee4fa1345 introduces a 5ms fuzz
+* for select(), it is not clear poll() has
+* similar behavior (returning a couple of ms
+* sooner than requested) as well. Just leave
+* the fuzz here. Remove it with a separate
+* patch if necessary */
+   if ((now+5) > con->next_period) {
+   con->next_period = now + RATE_LIMIT_PERIOD;
+   if (con->event_count >= RATE_LIMIT_ALLOWANCE)
+   (void)xenevtchn_unmask(con->xce_handle, 
con->local_port);
+   con->event_count = 0;
+   }
+}
+
 static void handle_ring_read(struct domain *dom)
 {
xenevtchn_port_or_error_t port;
@@ -1144,23 +1170,7 @@ void handle_io(void)
for (d = dom_head; d; d = d->next) {
struct console *con = &d->console;
 
-   /* CS 16257:955ee4fa1345 introduces a 5ms fuzz
-* for select(), it is not clear poll() has
-* similar behavior (returning a couple of ms
-* sooner than requested) as well. Just leave
-* the fuzz here. Remove it with a separate
-* patch if necessary */
-   if ((now+5) > con->next_period) {
-   con->next_period = now + RATE_LIMIT_PERIOD;
-   if (con->event_count >= RATE_LIMIT_ALLOWANCE) {
-   (void)xenevtchn_unmask(con->xce_handle, 
con->local_port);
-   }
-   con->event_count = 0;
-   }
-   }
-
-   for (d = dom_head; d; d = d->next) {
-   struct console *con = &d->console;
+   console_evtchn_unmask(con, (void *)now);
 
add_console_evtchn_fd(con, (void *)&next_timeout);
 
-- 
2.7.4


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

[Xen-devel] [PATCH 11/25 v6] xen/arm: vpl011: Add a new console_init function in xenconsole

This patch introduces a new console_init function. This function
initializes the console structure.

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

Changes since v5:
- Split this change in a separate patch.

 tools/console/daemon/io.c | 64 +--
 1 file changed, 39 insertions(+), 25 deletions(-)

diff --git a/tools/console/daemon/io.c b/tools/console/daemon/io.c
index a2a3496..9e92097 100644
--- a/tools/console/daemon/io.c
+++ b/tools/console/daemon/io.c
@@ -655,13 +655,10 @@ static bool watch_domain(struct domain *dom, bool watch)
return success;
 }
 
-
-static struct domain *create_domain(int domid)
+static int console_init(struct console *con, struct domain *dom)
 {
-   struct domain *dom;
char *s;
struct timespec ts;
-   struct console *con;
 
if (clock_gettime(CLOCK_MONOTONIC, &ts) < 0) {
dolog(LOG_ERR, "Cannot get time of day %s:%s:L%d",
@@ -669,6 +666,41 @@ static struct domain *create_domain(int domid)
return NULL;
}
 
+   con->master_fd = -1;
+   con->master_pollfd_idx = -1;
+   con->slave_fd = -1;
+   con->log_fd = -1;
+   con->ring_ref = -1;
+   con->local_port = -1;
+   con->remote_port = -1;
+   con->xce_pollfd_idx = -1;
+   con->next_period = ((long long)ts.tv_sec * 1000) + (ts.tv_nsec / 
100) + RATE_LIMIT_PERIOD;
+   con->d = dom;
+   con->xspath = xs_get_domain_path(xs, dom->domid);
+   s = realloc(con->xspath, strlen(con->xspath) +
+   strlen("/console") + 1);
+   if (s)
+   {
+   con->xspath = s;
+   strcat(con->xspath, "/console");
+   err = 0;
+   }
+
+   return err;
+}
+
+static void console_free(struct console *con)
+{
+   if (con->xspath)
+   free(con->xspath);
+}
+
+static struct domain *create_domain(int domid)
+{
+   struct domain *dom;
+   char *s;
+   struct console *con;
+
dom = calloc(1, sizeof *dom);
if (dom == NULL) {
dolog(LOG_ERR, "Out of memory %s:%s():L%d",
@@ -677,28 +709,10 @@ static struct domain *create_domain(int domid)
}
 
dom->domid = domid;
-
con = &dom->console;
-   con->xspath = xs_get_domain_path(xs, dom->domid);
-   s = realloc(con->xspath, strlen(con->xspath) +
-   strlen("/console") + 1);
-   if (s == NULL)
-   goto out;
-   con->xspath = s;
-   strcat(con->xspath, "/console");
 
-   con->master_fd = -1;
-   con->master_pollfd_idx = -1;
-   con->slave_fd = -1;
-   con->log_fd = -1;
-   con->xce_pollfd_idx = -1;
-   con->d = dom;
-
-   con->next_period = ((long long)ts.tv_sec * 1000) + (ts.tv_nsec / 
100) + RATE_LIMIT_PERIOD;
-
-   con->ring_ref = -1;
-   con->local_port = -1;
-   con->remote_port = -1;
+   if (console_init(con, dom))
+   goto out;
 
if (!watch_domain(dom, true))
goto out;
@@ -710,7 +724,7 @@ static struct domain *create_domain(int domid)
 
return dom;
  out:
-   free(con->xspath);
+   console_free(con);
free(dom);
return NULL;
 }
-- 
2.7.4


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

[Xen-devel] [PATCH 17/25 v6] xen/arm: vpl011: Add a new handle_console_tty function in xenconsole

This patch introduces a new handle_console_tty function. This function
performs read/write from/to console tty.

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

Changes since v5:
- Split this change in a separate patch.

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

diff --git a/tools/console/daemon/io.c b/tools/console/daemon/io.c
index 775fb04..4097673 100644
--- a/tools/console/daemon/io.c
+++ b/tools/console/daemon/io.c
@@ -1133,6 +1133,24 @@ static void add_console_tty_fd(struct console *con)
}
 }
 
+static void handle_console_tty(struct console *con)
+{
+   if (con->master_fd != -1 && con->master_pollfd_idx != -1) {
+   if (fds[con->master_pollfd_idx].revents &
+   ~(POLLIN|POLLOUT|POLLPRI))
+   console_handle_broken_tty(con, 
domain_is_valid(con->d->domid));
+   else {
+   if (fds[con->master_pollfd_idx].revents &
+   POLLIN)
+   handle_tty_read(con);
+   if (fds[con->master_pollfd_idx].revents &
+   POLLOUT)
+   handle_tty_write(con);
+   }
+   }
+   con->master_pollfd_idx = -1;
+}
+
 void handle_io(void)
 {
int ret;
@@ -1263,22 +1281,7 @@ void handle_io(void)
 
handle_console_ring(con);
 
-   if (con->master_fd != -1 && con->master_pollfd_idx != 
-1) {
-   if (fds[con->master_pollfd_idx].revents &
-   ~(POLLIN|POLLOUT|POLLPRI))
-   console_handle_broken_tty(con,
-  domain_is_valid(d->domid));
-   else {
-   if (fds[con->master_pollfd_idx].revents 
&
-   POLLIN)
-   handle_tty_read(con);
-   if (fds[con->master_pollfd_idx].revents 
&
-   POLLOUT)
-   handle_tty_write(con);
-   }
-   }
-
-   con->master_pollfd_idx = -1;
+   handle_console_tty(con);
 
if (d->last_seen != enum_pass)
shutdown_domain(d);
-- 
2.7.4


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

[Xen-devel] [PATCH 00/25 v6] SBSA UART emulation support in Xen

SBSA UART emulation for guests in Xen
==
Linaro has published VM System specification for ARM Processors, which
provides a set of guidelines for both guest OS and hypervisor implementations,
such that building OS images according to these guidelines guarantees
that those images can also run on hypervisors compliant with this specification.

One of the spec requirements is that the hypervisor must provide an
emulated SBSA UART as a serial console which meets the minimum requirements in
SBSA UART as defined in appendix B of the following
ARM Server Base Architecture Document:

https://static.docs.arm.com/den0029/a/Server_Base_System_Architecture_v3_1_ARM_DEN_0029A.pdf.

This feature allows the Xen guests to use SBSA compliant pl011 UART as
as a console.

Note that SBSA pl011 UART is a subset of full featured ARM pl011 UART and
supports only a subset of registers as mentioned below. It does not support
rx/tx DMA.

Currently, Xen supports paravirtualized (aka PV console) and an emulated serial
consoles. This feature will expose an emulated SBSA pl011 UART console to the
guest, which a user can access using xenconsole.

The device tree passed to the guest VM will contain the pl011 MMIO address
range and an irq for receiving rx/tx pl011 interrupts. The device tree format
is specified in Documentation/devicetree/bindings/serial/arm_sbsa_uart.txt.

The Xen hypervisor will expose two types of interfaces to the backend and domU.

The interface exposed to domU will be an emulated pl011 UART by emulating the
access to the following pl011 registers by the guest.

- Data register (DR)- RW
- Raw interrupt status register (RIS) - RO
- Masked interrupt status register (MIS)- RO
- Interrupt Mask (IMSC) - RW
- Interrupt Clear (ICR) - WO

It will also inject the pl011 interrupts to the guest in the following
conditions:

- incoming data in the rx buffer for the guest
- there is space in the tx buffer for the guest to write more data

The interface exposed to the backend will be the same PV console interface,
which minimizes the changes required in xenconsole to support a new pl011
console.

This interface has rx and tx ring buffers and an event channel for
sending/receiving events from the backend.

So essentially Xen handles the data on behalf of domU and the backend. Any data
written by domU is captured by Xen and written to the TX (OUT) ring buffer
and a pl011 event is raised to the backend to read the TX ring buffer.

Similarly on reciving a pl011 event, Xen injects an interrupt to guest to
indicate there is data available in the RX (IN) ring buffer.

The pl011 UART state is completely captured in the set of registers
mentioned above and this state is updated everytime there is an event from
the backend or there is register read/write access from domU.

For example, if domU has masked the rx interrupt in the IMSC register, then Xen
will not inject an interrupt to guest and will just update the RIS register.
Once the interrupt is unmasked by guest, the interrupt will be delivered to the
guest.

Changes summary:

Xen Hypervisor
===

1. Add emulation code to emulate read/write access to pl011 registers and pl011
interrupts:
- It emulates DR read/write by reading and writing from/to the IN and
OUT ring buffers and raising an event to dom0 when there is data in
the OUT ring buffer and injecting an interrupt to the guest when there
is data in the IN ring buffer.
- Other registers are related to interrupt management and essentially
control when interrupts are delivered to the guest.

2. Add a new domctl API to initialize vpl011 emulation in Xen.

3. Enable vpl011 emulation for a domain based on a libxl option passed during
domain creation.

Toolstack
==

1. Add a new option "vuart" in the domU configuration file to enable/disable
vuart.

2. Create a SBSA UART DT node in the guest device tree. It uses a fixed
vpl011 SPI IRQ number and MMIO address.

3. Call vpl011 init DOMCTL API to enable vpl011 emulation.

5. Add a new vuart xenstore node, which contains:
- ring-ref
- event channel
- buffer limit
- type

Xenconsoled

1. Split the domain structure to support multiple consoles.

2. Modify different APIs such as buffer_append() etc. to operate on the
console structure.

3. Add support for handling multiple consoles.

4. Add support for vuart console:

The vpl011 changes available at the following repo:

url: https://g...@git.linaro.org:/people/bhupinder.thakur/xen.git
branch: vpl011_v6

Kindly wait for one day to checkout the code from the above URL.

There are some TBD items which need to be looked at in the future:

1. Currently UEFI firmware logs the output to hvc console only. How can
UEFI firmware be made aware of pl011 console and how it can use it
as a console instead of hvc.

There was a discussion on this and it was decid

[Xen-devel] [PATCH 16/25 v6] xen/arm: vpl011: Add a new handle_console_ring function in xenconsole

This patch introduces a new handle_console_ring function. This function
reads the data from the ring buffer on receiving an event.

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

Changes since v5:
- Split this change in a separate patch.

 tools/console/daemon/io.c | 41 -
 1 file changed, 28 insertions(+), 13 deletions(-)

diff --git a/tools/console/daemon/io.c b/tools/console/daemon/io.c
index c272fe6..775fb04 100644
--- a/tools/console/daemon/io.c
+++ b/tools/console/daemon/io.c
@@ -935,17 +935,24 @@ static void console_evtchn_unmask(struct console *con, 
void *data)
}
 }
 
-static void handle_ring_read(struct domain *dom)
+static void handle_ring_read(struct console *con)
 {
xenevtchn_port_or_error_t port;
-   struct console *con = &dom->console;
 
-   if (dom->is_dead)
+   if (con->d->is_dead)
return;
 
if ((port = xenevtchn_pending(con->xce_handle)) == -1)
return;
 
+   if (port != con->local_port)
+   {
+   dolog(LOG_ERR, 
+ "Event received for invalid port %d, Expected port is 
%d\n",
+ port, con->local_port);
+   return;
+   }
+
con->event_count++;
 
buffer_append(con);
@@ -954,6 +961,21 @@ static void handle_ring_read(struct domain *dom)
(void)xenevtchn_unmask(con->xce_handle, port);
 }
 
+static void handle_console_ring(struct console *con)
+{
+   if (con->event_count < RATE_LIMIT_ALLOWANCE) {
+   if (con->xce_handle != NULL &&
+   con->xce_pollfd_idx != -1 &&
+   !(fds[con->xce_pollfd_idx].revents &
+ ~(POLLIN|POLLOUT|POLLPRI)) &&
+   (fds[con->xce_pollfd_idx].revents &
+POLLIN))
+   handle_ring_read(con);
+   }
+
+   con->xce_pollfd_idx = -1;
+}
+
 static void handle_xs(void)
 {
char **vec;
@@ -1238,15 +1260,8 @@ void handle_io(void)
struct console *con = &d->console;
 
n = d->next;
-   if (con->event_count < RATE_LIMIT_ALLOWANCE) {
-   if (con->xce_handle != NULL &&
-   con->xce_pollfd_idx != -1 &&
-   !(fds[con->xce_pollfd_idx].revents &
- ~(POLLIN|POLLOUT|POLLPRI)) &&
- (fds[con->xce_pollfd_idx].revents &
-  POLLIN))
-   handle_ring_read(d);
-   }
+
+   handle_console_ring(con);
 
if (con->master_fd != -1 && con->master_pollfd_idx != 
-1) {
if (fds[con->master_pollfd_idx].revents &
@@ -1263,7 +1278,7 @@ void handle_io(void)
}
}
 
-   con->xce_pollfd_idx = con->master_pollfd_idx = -1;
+   con->master_pollfd_idx = -1;
 
if (d->last_seen != enum_pass)
shutdown_domain(d);
-- 
2.7.4


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

[Xen-devel] [PATCH 13/25 v6] xen/arm: vpl011: Add a new add_console_evtchn_fd function in xenconsole

This patch introduces a new add_console_evtchn_fd function. This
function adds the console event channel FD to list of polled FDs.

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

Changes since v5:
- Split this change in a separate patch.

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

diff --git a/tools/console/daemon/io.c b/tools/console/daemon/io.c
index e4882e2..dc96203 100644
--- a/tools/console/daemon/io.c
+++ b/tools/console/daemon/io.c
@@ -1048,6 +1048,27 @@ static void reset_fds(void)
memset(fds, 0, sizeof(struct pollfd) * current_array_size);
 }
 
+static void add_console_evtchn_fd(struct console *con, void *data)
+{
+   long long next_timeout = *((long long *)data);
+
+   if (con->event_count >= RATE_LIMIT_ALLOWANCE) {
+   /* Determine if we're going to be the next time slice to expire 
*/
+   if (!next_timeout ||
+   con->next_period < next_timeout)
+   next_timeout = con->next_period;
+   } else if (con->xce_handle != NULL) {
+   if (buffer_available(con))
+   {
+   int evtchn_fd = xenevtchn_fd(con->xce_handle);
+   con->xce_pollfd_idx = set_fds(evtchn_fd,
+ POLLIN|POLLPRI);
+   }
+   }
+
+   *((long long *)data) = next_timeout;
+}
+
 void handle_io(void)
 {
int ret;
@@ -1125,18 +1146,7 @@ void handle_io(void)
for (d = dom_head; d; d = d->next) {
struct console *con = &d->console;
 
-   if (con->event_count >= RATE_LIMIT_ALLOWANCE) {
-   /* Determine if we're going to be the next time 
slice to expire */
-   if (!next_timeout ||
-   con->next_period < next_timeout)
-   next_timeout = con->next_period;
-   } else if (con->xce_handle != NULL) {
-   if (buffer_available(con)) {
-   int evtchn_fd = 
xenevtchn_fd(con->xce_handle);
-   con->xce_pollfd_idx = set_fds(evtchn_fd,
-   
POLLIN|POLLPRI);
-   }
-   }
+   add_console_evtchn_fd(con, (void *)&next_timeout);
 
if (con->master_fd != -1) {
short events = 0;
-- 
2.7.4


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

[Xen-devel] [PATCH 14/25 v6] xen/arm: vpl011: Add a new add_console_tty_fd function in xenconsole

This patch introduces a new add_console_tty_fd function. This function
adds the tty fd to the list of polled fds.

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

Changes since v5:
- Split this change in a separate patch.

 tools/console/daemon/io.c | 30 +-
 1 file changed, 17 insertions(+), 13 deletions(-)

diff --git a/tools/console/daemon/io.c b/tools/console/daemon/io.c
index dc96203..6321d78 100644
--- a/tools/console/daemon/io.c
+++ b/tools/console/daemon/io.c
@@ -1069,6 +1069,22 @@ static void add_console_evtchn_fd(struct console *con, 
void *data)
*((long long *)data) = next_timeout;
 }
 
+static void add_console_tty_fd(struct console *con)
+{
+   if (con->master_fd != -1) {
+   short events = 0;
+   if (!con->d->is_dead && ring_free_bytes(con))
+   events |= POLLIN;
+
+   if (!buffer_empty(&con->buffer))
+   events |= POLLOUT;
+
+   if (events)
+   con->master_pollfd_idx =
+   set_fds(con->master_fd, events|POLLPRI);
+   }
+}
+
 void handle_io(void)
 {
int ret;
@@ -1148,19 +1164,7 @@ void handle_io(void)
 
add_console_evtchn_fd(con, (void *)&next_timeout);
 
-   if (con->master_fd != -1) {
-   short events = 0;
-   if (!d->is_dead && ring_free_bytes(con))
-   events |= POLLIN;
-
-   if (!buffer_empty(&con->buffer))
-   events |= POLLOUT;
-
-   if (events)
-   con->master_pollfd_idx =
-   set_fds(con->master_fd,
-   events|POLLPRI);
-   }
+   add_console_tty_fd(con);
}
 
/* If any domain has been rate limited, we need to work
-- 
2.7.4


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

[Xen-devel] [PATCH 10/25 v6] xen/arm: vpl011: Modify xenconsole functions to take console structure as input

Xenconsole functions take domain structure as input. These functions shall be
modified to take console structure as input since these functions typically 
perform
console specific operations.

Also the console specific functions starting with prefix "domain_" shall be 
modified
to "console_" to indicate that these are console specific functions.

This patch is in preparation to support multiple consoles to support vuart 
console.

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

Changes since v3:
- The changes in xenconsole have been split into four patches. This is the 
second patch.

 tools/console/daemon/io.c | 79 +++
 1 file changed, 38 insertions(+), 41 deletions(-)

diff --git a/tools/console/daemon/io.c b/tools/console/daemon/io.c
index 6f5c69c..a2a3496 100644
--- a/tools/console/daemon/io.c
+++ b/tools/console/daemon/io.c
@@ -163,10 +163,10 @@ static int write_with_timestamp(int fd, const char *data, 
size_t sz,
return 0;
 }
 
-static void buffer_append(struct domain *dom)
+static void buffer_append(struct console *con)
 {
-   struct console *con = &dom->console;
struct buffer *buffer = &con->buffer;
+   struct domain *dom = con->d;
XENCONS_RING_IDX cons, prod, size;
struct xencons_interface *intf = con->interface;
 
@@ -296,12 +296,13 @@ static int create_hv_log(void)
return fd;
 }
 
-static int create_domain_log(struct domain *dom)
+static int create_console_log(struct console *con)
 {
char logfile[PATH_MAX];
char *namepath, *data, *s;
int fd;
unsigned int len;
+   struct domain *dom = con->d;
 
namepath = xs_get_domain_path(xs, dom->domid);
s = realloc(namepath, strlen(namepath) + 6);
@@ -342,10 +343,8 @@ static int create_domain_log(struct domain *dom)
return fd;
 }
 
-static void domain_close_tty(struct domain *dom)
+static void console_close_tty(struct console *con)
 {
-   struct console *con = &dom->console;
-
if (con->master_fd != -1) {
close(con->master_fd);
con->master_fd = -1;
@@ -417,7 +416,7 @@ void cfmakeraw(struct termios *termios_p)
 }
 #endif /* __sun__ */
 
-static int domain_create_tty(struct domain *dom)
+static int console_create_tty(struct console *con)
 {
const char *slave;
char *path;
@@ -426,7 +425,7 @@ static int domain_create_tty(struct domain *dom)
char *data;
unsigned int len;
struct termios term;
-   struct console *con = &dom->console;
+   struct domain *dom = con->d;
 
assert(con->slave_fd == -1);
assert(con->master_fd == -1);
@@ -487,7 +486,7 @@ static int domain_create_tty(struct domain *dom)
 
return 1;
 out:
-   domain_close_tty(dom);
+   console_close_tty(con);
return 0;
 }
  
@@ -526,10 +525,8 @@ static int xs_gather(struct xs_handle *xs, const char 
*dir, ...)
return ret;
 }
 
-static void domain_unmap_interface(struct domain *dom)
+static void console_unmap_interface(struct console *con)
 {
-   struct console *con = &dom->console;
-
if (con->interface == NULL)
return;
if (xgt_handle && con->ring_ref == -1)
@@ -540,11 +537,11 @@ static void domain_unmap_interface(struct domain *dom)
con->ring_ref = -1;
 }
  
-static int domain_create_ring(struct domain *dom)
+static int console_create_ring(struct console *con)
 {
int err, remote_port, ring_ref, rc;
char *type, path[PATH_MAX];
-   struct console *con = &dom->console;
+   struct domain *dom = con->d;
 
err = xs_gather(xs, con->xspath,
"ring-ref", "%u", &ring_ref,
@@ -563,7 +560,7 @@ static int domain_create_ring(struct domain *dom)
 
/* If using ring_ref and it has changed, remap */
if (ring_ref != con->ring_ref && con->ring_ref != -1)
-   domain_unmap_interface(dom);
+   console_unmap_interface(con);
 
if (!con->interface && xgt_handle) {
/* Prefer using grant table */
@@ -621,7 +618,7 @@ static int domain_create_ring(struct domain *dom)
con->remote_port = remote_port;
 
if (con->master_fd == -1) {
-   if (!domain_create_tty(dom)) {
+   if (!console_create_tty(con)) {
err = errno;
xenevtchn_close(con->xce_handle);
con->xce_handle = NULL;
@@ -632,7 +629,7 @@ static int domain_create_ring(struct domain *dom)
}
 
if (log_guest && (con->log_fd == -1))
-   con->log_fd = create_domain_log(dom);
+   con->log_fd = create_console_log(con);
 
  out:
return err;
@@ -648,7 +645,7 @@ static bool watch_domain(struct domain *dom, bool watch)
if (watch) {
success = xs_watch(xs, con->xspath,

[Xen-devel] [PATCH 06/25 v6] xen/arm: vpl011: Add a new domctl API to initialize vpl011

Add a new domctl API to initialize vpl011. It takes the GFN and console
backend domid as input and returns an event channel to be used for
sending and receiving events from Xen.

Xen will communicate with xenconsole using GFN as the ring buffer and
the event channel to transmit and receive pl011 data on the guest domain's
behalf.

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

Changes since v5:
- xc_dom_vpl011_init() will be compiled for both x86/arm architectures as there
  is nothing architecture specific in this function. This function will return 
  error when called for x86.
- Fixed coding style issues in libxl.

Changes since v4:
- Removed libxl__arch_domain_create_finish().
- Added a new function libxl__arch_build_dom_finish(), which is called at the 
last
  in libxl__build_dom(). This function calls the vpl011 initialization function 
now.

Changes since v3:
- Added a new arch specific function libxl__arch_domain_create_finish(), which
  calls the vpl011 initialization function. For x86 this function does not do
  anything.
- domain_vpl011_init() takes a pointer to a structure which contains all the 
  required information such as console_domid, gfn instead of passing parameters
  separately.
- Dropped a DOMCTL API defined for de-initializing vpl011 as that should be
  taken care when the domain is destroyed (and not dependent on userspace 
  libraries/applications).

Changes since v2:
- Replaced the DOMCTL APIs defined for get/set of event channel and GFN with 
  a set of DOMCTL APIs for initializing and de-initializing vpl011 emulation.

 tools/libxc/include/xenctrl.h | 18 ++
 tools/libxc/xc_domain.c   | 24 
 tools/libxl/libxl_arch.h  |  6 ++
 tools/libxl/libxl_arm.c   | 20 
 tools/libxl/libxl_dom.c   |  4 
 tools/libxl/libxl_x86.c   |  8 
 xen/arch/arm/domain.c |  5 +
 xen/arch/arm/domctl.c | 37 +
 xen/include/public/domctl.h   | 21 +
 9 files changed, 143 insertions(+)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index c51bb3b..423c6f3 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -886,6 +886,24 @@ int xc_vcpu_getcontext(xc_interface *xch,
vcpu_guest_context_any_t *ctxt);
 
 /**
+ * This function initializes the vpl011 emulation and returns
+ * the event to be used by the backend for communicating with
+ * the emulation code.
+ *
+ * @parm xch a handle to an open hypervisor interface
+ * @parm domid the domain to get information from
+ * @parm console_domid the domid of the backend console
+ * @parm gfn the guest pfn to be used as the ring buffer
+ * @parm evtchn the event channel to be used for events
+ * @return 0 on success, negative error on failure
+ */
+int xc_dom_vpl011_init(xc_interface *xch,
+   domid_t domid,
+   uint32_t console_domid,
+   xen_pfn_t gfn,
+   evtchn_port_t *evtchn);
+
+/**
  * This function returns information about the XSAVE state of a particular
  * vcpu of a domain. If extstate->size and extstate->xfeature_mask are 0,
  * the call is considered a query to retrieve them and the buffer is not
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index 3bab4e8..fab3c5e 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -343,6 +343,30 @@ int xc_domain_get_guest_width(xc_interface *xch, uint32_t 
domid,
 return 0;
 }
 
+int xc_dom_vpl011_init(xc_interface *xch,
+   domid_t domid,
+   uint32_t console_domid,
+   xen_pfn_t gfn,
+   evtchn_port_t *evtchn)
+{
+DECLARE_DOMCTL;
+int rc = 0;
+
+domctl.cmd = XEN_DOMCTL_vuart_op;
+domctl.domain = (domid_t)domid;
+domctl.u.vuart_op.cmd = XEN_DOMCTL_VUART_OP_INIT;
+domctl.u.vuart_op.type = XEN_DOMCTL_VUART_TYPE_VPL011;
+domctl.u.vuart_op.console_domid = console_domid;
+domctl.u.vuart_op.gfn = gfn;
+
+if ( (rc = do_domctl(xch, &domctl)) < 0 )
+return rc;
+
+*evtchn = domctl.u.vuart_op.evtchn;
+
+return rc;
+}
+
 int xc_domain_getinfo(xc_interface *xch,
   uint32_t first_domid,
   unsigned int max_doms,
diff --git a/tools/libxl/libxl_arch.h b/tools/libxl/libxl_arch.h
index 5e1fc60..118b92c 100644
--- a/tools/libxl/libxl_arch.h
+++ b/tools/libxl/libxl_arch.h
@@ -44,6 +44,12 @@ int libxl__arch_domain_finalise_hw_description(libxl__gc *gc,
   libxl_domain_build_info *info,
   struct xc_dom_image *dom);
 
+/* perform any pending hardware initialization */
+int libxl__arch_build_dom_finish(libxl__gc *gc,
+ libxl_domain_build_info *info,

[Xen-devel] [PATCH 19/25 v6] xen/arm: vpl011: Add a new console_open_log function in xenconsole

This patch introduces a console_open_log console_cleanup function. This function
opens the console log file.

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

Changes since v5:
- Split this change in a separate patch.

 tools/console/daemon/io.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/tools/console/daemon/io.c b/tools/console/daemon/io.c
index d004687..93fc8cc 100644
--- a/tools/console/daemon/io.c
+++ b/tools/console/daemon/io.c
@@ -1046,6 +1046,16 @@ static void handle_hv_logs(xenevtchn_handle *xce_handle, 
bool force)
(void)xenevtchn_unmask(xce_handle, port);
 }
 
+static void console_open_log(struct console *con)
+{
+   if (console_enabled(con))
+   {
+   if (con->log_fd != -1)
+   close(con->log_fd);
+   con->log_fd = create_console_log(con);
+   }
+}
+
 static void handle_log_reload(void)
 {
if (log_guest) {
@@ -1053,9 +1063,7 @@ static void handle_log_reload(void)
for (d = dom_head; d; d = d->next) {
struct console *con = &d->console;
 
-   if (con->log_fd != -1)
-   close(con->log_fd);
-   con->log_fd = create_console_log(con);
+   console_open_log(con);
}
}
 
-- 
2.7.4


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

[Xen-devel] [PATCH 18/25 v6] xen/arm: vpl011: Add a new console_cleanup function in xenconsole

This patch introduces a new console_cleanup function. This function
frees up the console resources.

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

Changes since v5:
- Split this change in a separate patch.

 tools/console/daemon/io.c | 29 -
 1 file changed, 20 insertions(+), 9 deletions(-)

diff --git a/tools/console/daemon/io.c b/tools/console/daemon/io.c
index 4097673..d004687 100644
--- a/tools/console/daemon/io.c
+++ b/tools/console/daemon/io.c
@@ -769,22 +769,33 @@ static void remove_domain(struct domain *dom)
}
 }
 
-static void cleanup_domain(struct domain *d)
+static void console_cleanup(struct console *con)
 {
-   struct console *con = &d->console;
-
-   console_close_tty(con);
-
if (con->log_fd != -1) {
close(con->log_fd);
con->log_fd = -1;
}
 
-   free(con->buffer.data);
-   con->buffer.data = NULL;
+   if (con->buffer.data)
+   {
+   free(con->buffer.data);
+   con->buffer.data = NULL;
+   }
+
+   if (con->xspath)
+   {
+   free(con->xspath);
+   con->xspath = NULL;
+   }
+}
+
+static void cleanup_domain(struct domain *d)
+{
+   struct console *con = &d->console;
+
+   console_close_tty(con);
 
-   free(con->xspath);
-   con->xspath = NULL;
+   console_cleanup(con);
 
remove_domain(d);
 }
-- 
2.7.4


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

[Xen-devel] [PATCH 20/25 v6] xen/arm: vpl011: Add a new console_close_evtchn function in xenconsole

This patch introduces a console_close_evtchn console_cleanup function. This 
function
closes the console event channel.

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

Changes since v5:
- Split this change in a separate patch.

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

diff --git a/tools/console/daemon/io.c b/tools/console/daemon/io.c
index 93fc8cc..54c91aa 100644
--- a/tools/console/daemon/io.c
+++ b/tools/console/daemon/io.c
@@ -800,6 +800,14 @@ static void cleanup_domain(struct domain *d)
remove_domain(d);
 }
 
+static void console_close_evtchn(struct console *con)
+{
+   if (con->xce_handle != NULL)
+   xenevtchn_close(con->xce_handle);
+
+   con->xce_handle = NULL;
+}
+
 static void shutdown_domain(struct domain *d)
 {
struct console *con = &d->console;
@@ -807,9 +815,7 @@ static void shutdown_domain(struct domain *d)
d->is_dead = true;
watch_domain(d, false);
console_unmap_interface(con);
-   if (con->xce_handle != NULL)
-   xenevtchn_close(con->xce_handle);
-   con->xce_handle = NULL;
+   console_close_evtchn(con);
 }
 
 static unsigned enum_pass = 0;
-- 
2.7.4


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

[Xen-devel] [PATCH 12/25 v6] xen/arm: vpl011: Add a new buffer_available function in xenconsole

This patch introduces a new buffer_available function to check if
more data is allowed to be buffered.

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

Changes since v5:
- Split this change in a separate patch.

 tools/console/daemon/io.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/tools/console/daemon/io.c b/tools/console/daemon/io.c
index 9e92097..e4882e2 100644
--- a/tools/console/daemon/io.c
+++ b/tools/console/daemon/io.c
@@ -163,6 +163,16 @@ static int write_with_timestamp(int fd, const char *data, 
size_t sz,
return 0;
 }
 
+static inline bool buffer_available(struct console *con)
+{
+   if (discard_overflowed_data ||
+   !con->buffer.max_capacity ||
+   con->buffer.size < con->buffer.max_capacity)
+   return true;
+   else
+   return false;
+}
+
 static void buffer_append(struct console *con)
 {
struct buffer *buffer = &con->buffer;
@@ -1121,9 +1131,7 @@ void handle_io(void)
con->next_period < next_timeout)
next_timeout = con->next_period;
} else if (con->xce_handle != NULL) {
-   if (discard_overflowed_data ||
-   !con->buffer.max_capacity ||
-   con->buffer.size < 
con->buffer.max_capacity) {
+   if (buffer_available(con)) {
int evtchn_fd = 
xenevtchn_fd(con->xce_handle);
con->xce_pollfd_idx = set_fds(evtchn_fd,

POLLIN|POLLPRI);
-- 
2.7.4


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

[Xen-devel] [PATCH 21/25 v6] xen/arm: vpl011: Add support for multiple consoles in xenconsole

This patch adds the support for multiple consoles and introduces the iterator
functions to operate on multiple consoles.

This patch is in preparation to support a new vuart console.

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

Changes since v5:
- Split this patch in multiple smaller patches.

Changes since v4:
- Changes to make event channel handling per console rather than per domain.

Changes since v3:
- The changes in xenconsole have been split into four patches. This is the 
third patch.

 tools/console/daemon/io.c | 174 +++---
 1 file changed, 134 insertions(+), 40 deletions(-)

diff --git a/tools/console/daemon/io.c b/tools/console/daemon/io.c
index 54c91aa..49f085c 100644
--- a/tools/console/daemon/io.c
+++ b/tools/console/daemon/io.c
@@ -90,12 +90,14 @@ struct buffer {
 };
 
 struct console {
+   const char *const ttyname;
int master_fd;
int master_pollfd_idx;
int slave_fd;
int log_fd;
struct buffer buffer;
-   char *xspath;
+   const char *const xspath;
+   const char *const log_suffix;
int ring_ref;
xenevtchn_handle *xce_handle;
int xce_pollfd_idx;
@@ -107,21 +109,112 @@ struct console {
struct domain *d;
 };
 
+struct console_data {
+   const char *const xsname;
+   const char *const ttyname;
+   const char *const log_suffix;
+};
+
+static struct console_data console_data[] = {
+   {
+   .xsname = "/console",
+   .ttyname = "tty",
+   .log_suffix = "",
+   },
+};
+
+#define MAX_CONSOLE (sizeof(console_data)/sizeof(struct console_data))
+
 struct domain {
int domid;
bool is_dead;
unsigned last_seen;
struct domain *next;
-   struct console console;
+   struct console console[MAX_CONSOLE];
 };
 
 static struct domain *dom_head;
 
+typedef void (*VOID_ITER_FUNC_ARG1)(struct console *);
+typedef bool (*BOOL_ITER_FUNC_ARG1)(struct console *);
+typedef int (*INT_ITER_FUNC_ARG1)(struct console *);
+typedef void (*VOID_ITER_FUNC_ARG2)(struct console *,  void *);
+typedef int (*INT_ITER_FUNC_ARG3)(struct console *,
+ struct domain *dom, void **);
+
 static inline bool console_enabled(struct console *con)
 {
return con->local_port != -1;
 }
 
+static inline void console_iter_void_arg1(struct domain *d,
+ VOID_ITER_FUNC_ARG1 iter_func)
+{
+   int i = 0;
+   struct console *con = &d->console[0];
+
+   for (i = 0; i < MAX_CONSOLE; i++, con++)
+   {
+   iter_func(con);
+   }
+}
+
+static inline void console_iter_void_arg2(struct domain *d,
+ VOID_ITER_FUNC_ARG2 iter_func,
+ void *iter_data)
+{
+   int i = 0;
+   struct console *con = &d->console[0];
+
+   for (i = 0; i < MAX_CONSOLE; i++, con++)
+   {
+   iter_func(con, iter_data);
+   }
+}
+
+static inline bool console_iter_bool_arg1(struct domain *d,
+ BOOL_ITER_FUNC_ARG1 iter_func)
+{
+   int i = 0;
+   struct console *con = &d->console[0];
+
+   for (i = 0; i < MAX_CONSOLE; i++, con++)
+   {
+   if (iter_func(con))
+   return true;
+   }
+   return false;
+}
+
+static inline int console_iter_int_arg1(struct domain *d,
+   INT_ITER_FUNC_ARG1 iter_func)
+{
+   int i = 0;
+   struct console *con = &d->console[0];
+
+   for (i = 0; i < MAX_CONSOLE; i++, con++)
+   {
+   if (iter_func(con))
+   return 1;
+   }
+   return 0;
+}
+
+static inline int console_iter_int_arg3(struct domain *d,
+   INT_ITER_FUNC_ARG3 iter_func,
+   void **iter_data)
+{
+   int i = 0;
+   struct console *con = &d->console[0];
+
+   for (i = 0; i < MAX_CONSOLE; i++, con++)
+   {
+   if (iter_func(con, d, iter_data))
+   return 1;
+   }
+   return 0;
+}
+
 static int write_all(int fd, const char* buf, size_t len)
 {
while (len) {
@@ -336,7 +429,7 @@ static int create_console_log(struct console *con)
return -1;
}
 
-   snprintf(logfile, PATH_MAX-1, "%s/guest-%s.log", log_dir, data);
+   snprintf(logfile, PATH_MAX-1, "%s/guest-%s%s.log", log_dir, data, 
con->log_suffix);
free(data);
logfile[PATH_MAX-1] = '\0';
 
@@ -488,7 +581,7 @@ static int console_create_tty(struct console *con)
}
free(path);
 
-   success = (asprintf(&path, "%s/tty", con->xspath) != -1);
+   success = (asprintf(&path, "%s/%s", con->xspath, con->ttyname) != -1);
if (!success)
goto out;
success =

[Xen-devel] [PATCH 23/25 v6] xen/arm: vpl011: Add a new vuart console type to xenconsole client

Add a new console type VUART to connect to guest's emualated vuart
console.

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

Changes since v4:
- Removed the vuart compile time flag so that vuart code is compiled always.

Changes since v3:
- The vuart console support is under CONFIG_VUART_CONSOLE option.
- Since there is a change from last review, I have not included
  reviewed-by tag from Stefano and acked-by tag from Wei.

 tools/console/client/main.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/tools/console/client/main.c b/tools/console/client/main.c
index 99f..f7139b3 100644
--- a/tools/console/client/main.c
+++ b/tools/console/client/main.c
@@ -76,7 +76,7 @@ static void usage(const char *program) {
   "\n"
   "  -h, --help   display this help and exit\n"
   "  -n, --num N  use console number N\n"
-  "  --type TYPE  console type. must be 'pv' or 'serial'\n"
+  "  --type TYPE  console type. must be 'pv', 'serial' or 
'vuart'\n"
   "  --start-notify-fd N file descriptor used to notify parent\n"
   , program);
 }
@@ -264,6 +264,7 @@ typedef enum {
CONSOLE_INVAL,
CONSOLE_PV,
CONSOLE_SERIAL,
+   CONSOLE_VUART,
 } console_type;
 
 static struct termios stdin_old_attr;
@@ -343,6 +344,7 @@ int main(int argc, char **argv)
char *end;
console_type type = CONSOLE_INVAL;
bool interactive = 0;
+   char *console_names = "serial, pv, vuart";
 
if (isatty(STDIN_FILENO) && isatty(STDOUT_FILENO))
interactive = 1;
@@ -361,9 +363,12 @@ int main(int argc, char **argv)
type = CONSOLE_SERIAL;
else if (!strcmp(optarg, "pv"))
type = CONSOLE_PV;
+   else if (!strcmp(optarg, "vuart"))
+   type = CONSOLE_VUART;
else {
fprintf(stderr, "Invalid type argument\n");
-   fprintf(stderr, "Console types supported are: 
serial, pv\n");
+   fprintf(stderr, "Console types supported are: 
%s\n",
+   console_names);
exit(EINVAL);
}
break;
@@ -436,6 +441,10 @@ int main(int argc, char **argv)
else
snprintf(path, strlen(dom_path) + 
strlen("/device/console/%d/tty") + 5, "%s/device/console/%d/tty", dom_path, 
num);
}
+   if (type == CONSOLE_VUART) {
+   snprintf(path, strlen(dom_path) + strlen("/vuart/0/tty") + 1,
+"%s/vuart/0/tty", dom_path);
+   }
 
/* FIXME consoled currently does not assume domain-0 doesn't have a
   console which is good when we break domain-0 up.  To keep us
-- 
2.7.4


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

[Xen-devel] [PATCH 22/25 v6] xen/arm: vpl011: Add support for vuart console in xenconsole

This patch finally adds the support for vuart console. It adds
two new fields in the console initialization:

- optional
- prefer_gnttab

optional flag tells whether the console is optional.

prefer_gnttab tells whether the ring buffer should be allocated using
grant table.

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

Changes since v4:
- Renamed VUART_CFLAGS- to CFLAGS_vuart- in the Makefile as per the convention.

 config/arm32.mk   |  1 +
 config/arm64.mk   |  1 +
 tools/console/Makefile|  3 ++-
 tools/console/daemon/io.c | 29 -
 4 files changed, 32 insertions(+), 2 deletions(-)

diff --git a/config/arm32.mk b/config/arm32.mk
index f95228e..b9f23fe 100644
--- a/config/arm32.mk
+++ b/config/arm32.mk
@@ -1,5 +1,6 @@
 CONFIG_ARM := y
 CONFIG_ARM_32 := y
+CONFIG_VUART_CONSOLE := y
 CONFIG_ARM_$(XEN_OS) := y
 
 CONFIG_XEN_INSTALL_SUFFIX :=
diff --git a/config/arm64.mk b/config/arm64.mk
index aa45772..861d0a4 100644
--- a/config/arm64.mk
+++ b/config/arm64.mk
@@ -1,5 +1,6 @@
 CONFIG_ARM := y
 CONFIG_ARM_64 := y
+CONFIG_VUART_CONSOLE := y
 CONFIG_ARM_$(XEN_OS) := y
 
 CONFIG_XEN_INSTALL_SUFFIX :=
diff --git a/tools/console/Makefile b/tools/console/Makefile
index c8b0300..1cddb6e 100644
--- a/tools/console/Makefile
+++ b/tools/console/Makefile
@@ -11,6 +11,7 @@ LDLIBS += $(SOCKET_LIBS)
 
 LDLIBS_xenconsoled += $(UTIL_LIBS)
 LDLIBS_xenconsoled += -lrt
+CFLAGS_vuart-$(CONFIG_VUART_CONSOLE) = -DCONFIG_VUART_CONSOLE
 
 BIN  = xenconsoled xenconsole
 
@@ -28,7 +29,7 @@ clean:
 distclean: clean
 
 daemon/main.o: daemon/_paths.h
-daemon/io.o: CFLAGS += $(CFLAGS_libxenevtchn) $(CFLAGS_libxengnttab)
+daemon/io.o: CFLAGS += $(CFLAGS_libxenevtchn) $(CFLAGS_libxengnttab) 
$(CFLAGS_vuart-y)
 xenconsoled: $(patsubst %.c,%.o,$(wildcard daemon/*.c))
$(CC) $(LDFLAGS) $^ -o $@ $(LDLIBS) $(LDLIBS_libxenevtchn) 
$(LDLIBS_libxengnttab) $(LDLIBS_xenconsoled) $(APPEND_LDFLAGS)
 
diff --git a/tools/console/daemon/io.c b/tools/console/daemon/io.c
index 49f085c..c6d4cae 100644
--- a/tools/console/daemon/io.c
+++ b/tools/console/daemon/io.c
@@ -107,12 +107,16 @@ struct console {
xenevtchn_port_or_error_t remote_port;
struct xencons_interface *interface;
struct domain *d;
+   bool optional;
+   bool prefer_gnttab;
 };
 
 struct console_data {
const char *const xsname;
const char *const ttyname;
const char *const log_suffix;
+   bool optional;
+   bool prefer_gnttab;
 };
 
 static struct console_data console_data[] = {
@@ -120,7 +124,18 @@ static struct console_data console_data[] = {
.xsname = "/console",
.ttyname = "tty",
.log_suffix = "",
+   .optional = false,
+   .prefer_gnttab = true,
},
+#if defined(CONFIG_VUART_CONSOLE)
+   {
+   .xsname = "/vuart/0",
+   .ttyname = "tty",
+   .log_suffix = "-vuart0",
+   .optional = true,
+   .prefer_gnttab = false,
+   },
+#endif
 };
 
 #define MAX_CONSOLE (sizeof(console_data)/sizeof(struct console_data))
@@ -655,8 +670,18 @@ static int console_create_ring(struct console *con)
"ring-ref", "%u", &ring_ref,
"port", "%i", &remote_port,
NULL);
+
if (err)
+   {
+   /*
+* This is a normal condition for optional consoles: they might 
not be
+* present on xenstore at all. In that case, just return 
without error.
+   */
+   if (con->optional)
+   err = 0;
+
goto out;
+   }
 
snprintf(path, sizeof(path), "%s/type", con->xspath);
type = xs_read(xs, XBT_NULL, path, NULL);
@@ -670,7 +695,9 @@ static int console_create_ring(struct console *con)
if (ring_ref != con->ring_ref && con->ring_ref != -1)
console_unmap_interface(con);
 
-   if (!con->interface && xgt_handle) {
+   if (!con->interface &&
+   xgt_handle &&
+   con->prefer_gnttab) {
/* Prefer using grant table */
con->interface = xengnttab_map_grant_ref(xgt_handle,
dom->domid, GNTTAB_RESERVED_CONSOLE,
-- 
2.7.4


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

[Xen-devel] [PATCH 25/25 v6] xen/arm: vpl011: Update documentation for vuart console support

1. Update documentation for a new vuart option added.
2. Update documentation about SPI irq reserved for vuart.

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

Changes since v4:
- Minor change to rename "pl011" to "sbsa_uart". Since it is a minor change I 
have
  retained the reviewed-by and acked-by tags.

 docs/man/xl.cfg.pod.5.in |  9 +
 docs/misc/console.txt| 44 +---
 2 files changed, 42 insertions(+), 11 deletions(-)

diff --git a/docs/man/xl.cfg.pod.5.in b/docs/man/xl.cfg.pod.5.in
index 79cb2ea..75f9169 100644
--- a/docs/man/xl.cfg.pod.5.in
+++ b/docs/man/xl.cfg.pod.5.in
@@ -1105,6 +1105,15 @@ Allow a guest to access specific physical IRQs.
 It is recommended to only use this option for trusted VMs under
 administrator's control.
 
+If the virtual uart is enabled then irq 32 is reserved for it. By
+default, it is disabled. If the user specifies the following option in
+the VM config file then the vuart gets enabled. Today, only the
+"sbsa_uart" model is supported.
+
+vuart = "sbsa_uart"
+
+Currently vuart console is available only for ARM64.
+
 =item B
 
 Limit the guest to using at most N event channels (PV interrupts).
diff --git a/docs/misc/console.txt b/docs/misc/console.txt
index 16da805..d081acc 100644
--- a/docs/misc/console.txt
+++ b/docs/misc/console.txt
@@ -19,7 +19,20 @@ The first PV console path in xenstore remains:
 
 /local/domain/$DOMID/console
 
-the other PV consoles follow the conventional xenstore device path and
+The virtual UART console path in xenstore is defined as:
+
+/local/domain/$DOMID/vuart/0
+
+The vuart console provides access to a virtual SBSA UART on ARM64 systems.
+To enable vuart the following line has to be added to the guest configuration
+file:
+
+vuart = "sbsa_uart"
+
+In Linux you can select the virtual SBSA UART by using the "ttyAMA0"
+console instead of "hvc0".
+
+The other PV consoles follow the conventional xenstore device path and
 live in:
 
 /local/domain/$DOMID/device/console/$DEVID.
@@ -61,6 +74,14 @@ output = pty
 The backend will write the pty device name to the "tty" node in the
 console frontend.
 
+For the PV console the tty node is added at
+
+/local/domain/$DOMID/console/tty
+
+For the virtual UART console the tty node is added at
+
+/local/domain/$DOMID/vuart/0/tty
+
 If the toolstack wants a listening Unix domain socket to be created at path
 , a connection accepted and data proxied to the console, it will write:
 
@@ -79,8 +100,8 @@ For example:
 ioemu
 
 The supported values are only xenconsoled or ioemu; xenconsoled has
-several limitations: it can only be used for the first PV console and it
-can only connect to a pty.
+several limitations: it can only be used for the first PV or virtual UART
+console and it can only connect to a pty.
 
 Emulated serials are provided by qemu-dm only to hvm guests; the number
 of emulated serials depends on how many "-serial" command line options
@@ -90,14 +111,15 @@ xenstore in the following path:
 
 /local/domain/$DOMID/serial/$SERIAL_NUM/tty
 
-xenconsole is the tool to connect to a PV console or an emulated serial
-that has a pty as output. Xenconsole takes a domid as parameter plus an
-optional console type (pv for PV consoles or serial for emulated
-serials) and console number. Depending on the type and console
-number, xenconsole will look for the tty node in different xenstore
-paths, as described above.  If the user doesn't specify the console type
-xenconsole will try to guess: if the guest is a pv guest it defaults to
-PV console, if the guest is an hvm guest it defaults to emulated serial.
+xenconsole is the tool to connect to a PV or virtual UART console or an
+emulated serial that has a pty as output. Xenconsole takes a domid as
+parameter plus an optional console type (pv for PV consoles, vuart for
+virtual UART or serial for emulated serials) and console number.
+Depending on the type and console number, xenconsole will look for the tty
+node in different xenstore paths, as described above.  If the user doesn't
+specify the console type xenconsole will try to guess: if the guest is a pv
+guest it defaults to PV console, if the guest is an hvm guest it defaults to
+emulated serial.
 
 By default xl creates a pv console for hvm guests, plus an emulated
 serial if the user specified 'serial = "pty"' in the VM config file.
-- 
2.7.4


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

[Xen-devel] [PATCH 24/25 v6] xen/arm: vpl011: Add a pl011 uart DT node in the guest device tree

The SBSA UART node format is as specified in
Documentation/devicetree/bindings/serial/arm_sbsa_uart.txt and given below:

ARM SBSA defined generic UART
--
This UART uses a subset of the PL011 registers and consequently lives
in the PL011 driver. It's baudrate and other communication parameters
cannot be adjusted at runtime, so it lacks a clock specifier here.

Required properties:
- compatible: must be "arm,sbsa-uart"
- reg: exactly one register range
- interrupts: exactly one interrupt specifier
- current-speed: the (fixed) baud rate set by the firmware

Currently the baud rate of 115200 has been selected as a default value,
which is one of the valid baud rate setttings. Higher baud rate was
selected since an emulated pl011 can support any valid baud rate without
any limitation of the hardware.

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

 tools/libxl/libxl_arm.c | 52 +++--
 1 file changed, 50 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index e3e5791..9eee50c 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -44,10 +44,22 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
 uint32_t nr_spis = 0;
 unsigned int i;
 
+/*
+ * If pl011 vuart is enabled then increment the nr_spis to allow allocation
+ * of SPI VIRQ for pl011.
+ */
+if (d_config->b_info.arch_arm.vuart)
+nr_spis += (GUEST_VPL011_SPI - 32) + 1;
+
 for (i = 0; i < d_config->b_info.num_irqs; i++) {
 uint32_t irq = d_config->b_info.irqs[i];
 uint32_t spi;
 
+if (d_config->b_info.arch_arm.vuart && (irq == GUEST_VPL011_SPI)) {
+LOG(ERROR, "Physical IRQ %u conflicting with pl011 SPI\n", irq);
+return ERROR_FAIL;
+}
+
 if (irq < 32)
 continue;
 
@@ -130,9 +142,10 @@ static struct arch_info {
 const char *guest_type;
 const char *timer_compat;
 const char *cpu_compat;
+const char *uart_compat;
 } arch_info[] = {
-{"xen-3.0-armv7l",  "arm,armv7-timer", "arm,cortex-a15" },
-{"xen-3.0-aarch64", "arm,armv8-timer", "arm,armv8" },
+{"xen-3.0-armv7l",  "arm,armv7-timer", "arm,cortex-a15", "arm,sbsa-uart" },
+{"xen-3.0-aarch64", "arm,armv8-timer", "arm,armv8", "arm,sbsa-uart" },
 };
 
 /*
@@ -590,6 +603,38 @@ static int make_hypervisor_node(libxl__gc *gc, void *fdt,
 return 0;
 }
 
+static int make_vpl011_uart_node(libxl__gc *gc, void *fdt,
+ const struct arch_info *ainfo,
+ struct xc_dom_image *dom)
+{
+int res;
+gic_interrupt intr;
+
+res = fdt_begin_node(fdt, "sbsa-pl011");
+if (res) return res;
+
+res = fdt_property_compat(gc, fdt, 1, ainfo->uart_compat);
+if (res) return res;
+
+res = fdt_property_regs(gc, fdt, ROOT_ADDRESS_CELLS, ROOT_SIZE_CELLS,
+1,
+GUEST_PL011_BASE, GUEST_PL011_SIZE);
+if (res) return res;
+
+set_interrupt(intr, GUEST_VPL011_SPI, 0xf, DT_IRQ_TYPE_LEVEL_HIGH);
+
+res = fdt_property_interrupts(gc, fdt, &intr, 1);
+if (res) return res;
+
+/* Use a default baud rate of 115200. */
+fdt_property_u32(fdt, "current-speed", 115200);
+
+res = fdt_end_node(fdt);
+if (res) return res;
+
+return 0;
+}
+
 static const struct arch_info *get_arch_info(libxl__gc *gc,
  const struct xc_dom_image *dom)
 {
@@ -889,6 +934,9 @@ next_resize:
 FDT( make_timer_node(gc, fdt, ainfo, xc_config->clock_frequency) );
 FDT( make_hypervisor_node(gc, fdt, vers) );
 
+if (info->arch_arm.vuart)
+FDT( make_vpl011_uart_node(gc, fdt, ainfo, dom) );
+
 if (pfdt)
 FDT( copy_partial_fdt(gc, fdt, pfdt) );
 
-- 
2.7.4


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

Re: [Xen-devel] preparations for 4.8.2

2017-07-17 Thread Lars Kurth

> I tried to follow the instructions in README for match-xsa. I believe
> the xsa-list-send script in step 3 depends on xsa.git, which I don't
> have access to.
That is unfortunately correct: we ought to fix this.
Lars


On 17/07/2017, 12:40, "Wei Liu"  wrote:

>On Mon, Jul 17, 2017 at 09:17:23AM +0100, Lars Kurth wrote:
>> Folks,
>> 
>> I didn't run the XSA script. Maybe someone can have a go and test out
>>the
>> instructions in 
>> 
>>https://xenbits.xenproject.org/gitweb/?p=people/larsk/xen-release-scripts
>>.g
>> it;a=summary
>> The scripts does requireS XSA.GIT to be checked out, but can be changed
>> easily to fetch XSAs from xenbits: line 26, and then follow $XSADIR
>> 
>> In fact --xsadir http://xenbits.xenproject.org/xsa may just work
>> 
>> Lars
>> 
>
>I tried to follow the instructions in README for match-xsa. I believe
>the xsa-list-send script in step 3 depends on xsa.git, which I don't
>have access to.

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

[Xen-devel] Xen 4.10 Development Update

This email only tracks big items for xen.git tree. Please reply for items you
woulk like to see in 4.10 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 twice a
year. The upcoming 4.10 timeline are as followed:

* Last posting date: September 15th, 2017
* Hard code freeze: September 29th, 2017
* RC1: TBD
* Release: December 2, 2017

Note that we don't have freeze exception scheme anymore. All patches
that wish to go into 4.10 must be posted no later than the last posting
date. All patches posted after that date will be automatically queued
into next release.

RCs will be arranged immediately after freeze.

We recently introduced a jira instance to track all the tasks (not only big)
for the project. See: https://xenproject.atlassian.net/projects/XEN/issues.

Most of the tasks tracked by this e-mail also have a corresponding jira task
referred by XEN-N.

I have started to include the version number of series associated to each
feature. Can each owner send an update on the version number if the series
was posted upstream?

= Projects =

== Hypervisor == 

*  Per-cpu tasklet
  -  XEN-28
  -  Konrad Rzeszutek Wilk

*  Add support of rcu_idle_{enter,exit}
  -  XEN-27
  -  Dario Faggioli

=== x86 === 

*  Allow ioreq server interface to support XenGT (v7)
  -  XEN-43
  -  Yu Zhang
  -  Paul Durrant

*  PVHv2 support
  -  XEN-44
  -  Roger Pau Monne

*  vNVDIMM support for HVM (RFC)
  -  XEN-45
  -  Haozhong Zhang

*  Completion of the x86 insn emulator (as far as possible)
  -  XEN-46
  -  Jan Beulich

*  Getting guest CPUID handling into a better shape
  -  XEN-47
  -  Andrew Cooper

*  Enable L2 Cache Allocation Technology (v8)
  -  XEN-37
  -  Yi Sun

*  Enable Memory Bandwidth Allocation (RFC)
  -  XEN-48
  -  Yi Sun

*  Intel LMCE support: (v2)
  -  XEN-68
  -  Haozhon Zhang

=== ARM === 

*  Support Tegra SoCs (RFC)
  -  XEN-49
  -  Kyle Temkin

*  Altp2m for ARM
  -  XEN-94
  -  Sergej Proskurin

*  SMMUv3
  -  XEN-25
  -  Sameer Goel
  -  Shanker Donthineni

*  PL011 emulation (v6)
  -  XEN-97
  -  Bhupinder Thakur

== Toolstack == 

*  Libxl PVSCSI support (v13)
  -  XEN-50
  -  Olaf Hering

*  Libxl depriv QEMU
  -  Ian Jackson

*  Remove blktap2
  -  XEN-8
  -  Wei Liu

== Mini-OS == 

== PV Drivers == 

*  Xen transport for 9pfs
  -  XEN-51
  -  Stefano Stabellini

*  PV calls
  -  XEN-63
  -  Stefano Stabellini

*  Multi-touch
  -  Oleksandr Andrushchenko
  -  Oleksanr Grytsov

*  Sound
  -  Oleksandr Andrushchenko
  -  Oleksanr Grytsov

*  Display
  -  Oleksandr Andrushchenko
  -  Oleksanr Grytsov

== Testing == 

*  Continuous fuzzing of Xen code using Google oss-fuzz
  -  Wei Liu

== Completed == 

*  ITS emulation (Dom0 only) (v1)
  -  XEN-95
  -  Andre Przywara



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

Re: [Xen-devel] ARM: Adjusting guest memory size through xl mem-{set|max} fails


(+Wei and Ian)

Hi Sergej

On 17/07/17 13:04, Sergej Proskurin wrote:

Hi all,

My setup comprises an ARMv7 (Arndale, Linux kernel v4.11.6) and an ARMv8
(LeMaker HiKey, Linux kernel v4.9.0) development board. On both boards,
I have Xen version 4.10-unstable running with the associated tools to
manage a domu.

Currently, I am trying to get xl mem-{set|max} to work on both
architectures. Unfortunately, both command invocations fail with the
following message (I remember using xl mem-{set|max} on ARMv7 before
with Xen version 4.7 and 4.8):

---
xl: libxl.c:339: libxl_defbool_val: Assertion
`!libxl_defbool_is_default(db)' failed.
Aborted
---


I haven't myself tried to use xl mem-{set|max}. Looking at the assert, 
you hit because a boolean is not initialized. It would be interesting to 
know which one.


I have CCed the tools maintainers to get more feedback.

Cheers,



The domu is created with the following parameters:

---
kernel= "/boot/zImage"
name = "domu"
memory = 512
vcpus = 2
disk=[ 'phy:/dev/vg0/VG0, xvda,w' ]
extra = 'console=hvc0 xencons=tty root=/dev/xvda rw'
---

My Kernel versions have CONFIG_XEN_BALLOON flag set (see ARMv7 example
Linux .config below).

---
$ cat .config | grep -i XEN
CONFIG_XEN_DOM0=y
CONFIG_XEN=y
CONFIG_XEN_BLKDEV_FRONTEND=y
CONFIG_XEN_BLKDEV_BACKEND=y
# CONFIG_XEN_SCSI_FRONTEND is not set
CONFIG_XEN_NETDEV_FRONTEND=y
CONFIG_XEN_NETDEV_BACKEND=y
CONFIG_INPUT_XEN_KBDDEV_FRONTEND=y
CONFIG_HVC_XEN=y
CONFIG_HVC_XEN_FRONTEND=y
# CONFIG_TCG_XEN is not set
# CONFIG_XEN_WDT is not set
CONFIG_XEN_FBDEV_FRONTEND=y
# Xen driver support
CONFIG_XEN_BALLOON=y
CONFIG_XEN_SCRUB_PAGES=y
CONFIG_XEN_DEV_EVTCHN=y
CONFIG_XEN_BACKEND=y
CONFIG_XENFS=y
CONFIG_XEN_COMPAT_XENFS=y
CONFIG_XEN_SYS_HYPERVISOR=y
CONFIG_XEN_XENBUS_FRONTEND=y
CONFIG_XEN_GNTDEV=m
CONFIG_XEN_GRANT_DEV_ALLOC=m
CONFIG_SWIOTLB_XEN=y
CONFIG_XEN_PRIVCMD=y
CONFIG_XEN_AUTO_XLATE=y
---

Besides, I can see in the dmesg output that the balloon driver gets
initialized:

---
# dmesg | grep -i balloon
[0.180942] xen:balloon: Initialising balloon driver
[0.187103] xen_balloon: Initialising balloon driver
---

It would be great if someone would help me to resolve this issue as I am
obviously missing something. Thank you very much in advance.

Best regards,
~Sergej


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



--
Julien Grall

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

Re: [Xen-devel] [PATCH RFC] tools: Drop xc_cpuid_check() and bindings

2017-07-17 Thread Christian Lindig

> On 17. Jul 2017, at 13:38, Andrew Cooper  wrote:
> 
> It turns out that Xapi has a library function using it, but that
> function is dead so can be removed.

I am fine with the removal of the OCaml bindings and the patch for the OCaml 
code. If the code is fundamentally broken it should be removed in any case but 
like you already said, we are not aware of any clients.

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

[Xen-devel] [PATCH] docs: Fix the markdown for the com{1, 2} keyword command line documentation

No change in content.

Signed-off-by: Andrew Cooper 
---
CC: George Dunlap 
CC: Ian Jackson 
CC: Jan Beulich 
CC: Konrad Rzeszutek Wilk 
CC: Stefano Stabellini 
CC: Tim Deegan 
CC: Wei Liu 
---
 docs/misc/xen-command-line.markdown | 48 +++--
 1 file changed, 25 insertions(+), 23 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index 6eb5cfc..3f90c3b 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -336,31 +336,33 @@ will be considered a positional parameter.
 The syntax consists of
 com1=(comma-separated positional parameters),(comma separated name-value pairs)
 
-The accepted name keywords for name=value pairs are
- * `baud` - accepts integer baud rate (eg. 115200) or `auto`
- * `bridge`- Similar to bridge-bdf in positional parameters.
- Used to determine the PCI bridge to access the UART device.
- Notation is xx:xx.xx :.
- * `clock-hz`- accepts large integers to setup UART clock frequencies.
-   Do note - these values are multiplied by 16.
- * `data-bits` - integer between 5 and 8
- * `dev` - accepted values are `pci` OR `amt`. If this option
-   is used to specify if the serial device is pci-based. The io_base
-   cannot be specified when `dev=pci` or `dev=amt` is used.
- * `io-base` - accepts integer which specified IO base port for UART registers
- * `irq` - IRQ number to use
- * `parity` - accepted values are same as positional parameters
- * `port` - Used to specify which port the PCI serial device is located on
-Notation is xx:xx.xx :.
- * `reg-shift` - register shifts required to set UART registers
- * `reg-width` - register width required to set UART registers
- (only accepts 1 and 4)
- * `stop-bits` - only accepts 1 or 2 for the number of stop bits
+The accepted name keywords for name=value pairs are:
+
+* `baud` - accepts integer baud rate (eg. 115200) or `auto`
+* `bridge`- Similar to bridge-bdf in positional parameters.
+Used to determine the PCI bridge to access the UART device.
+Notation is xx:xx.x `:.`
+* `clock-hz`- accepts large integers to setup UART clock frequencies.
+  Do note - these values are multiplied by 16.
+* `data-bits` - integer between 5 and 8
+* `dev` - accepted values are `pci` OR `amt`. If this option
+  is used to specify if the serial device is pci-based. The io_base
+  cannot be specified when `dev=pci` or `dev=amt` is used.
+* `io-base` - accepts integer which specified IO base port for UART registers
+* `irq` - IRQ number to use
+* `parity` - accepted values are same as positional parameters
+* `port` - Used to specify which port the PCI serial device is located on
+   Notation is xx:xx.x `:.`
+* `reg-shift` - register shifts required to set UART registers
+* `reg-width` - register width required to set UART registers
+(only accepts 1 and 4)
+* `stop-bits` - only accepts 1 or 2 for the number of stop bits
 
 The following are examples of correct specifications:
-`com1=115200,8n1,0x3f8,4`
-`com1=115200,8n1,0x3f8,4,reg_width=4,reg_shift=2`
-`com1=baud=115200,parity=n,stop_bits=1,io_base=0x3f8,reg_width=4`
+
+com1=115200,8n1,0x3f8,4
+com1=115200,8n1,0x3f8,4,reg_width=4,reg_shift=2
+com1=baud=115200,parity=n,stop_bits=1,io_base=0x3f8,reg_width=4
 
 ### conring\_size
 > `= `
-- 
2.1.4


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

Re: [Xen-devel] [PATCH] arm/p2m: Cleanup access to the host's p2m


Hello,

Please CC the respective maintainers when sending a patch on xen-devel.

On 04/07/17 13:53, Sergej Proskurin wrote:

This commit substitutes the direct access of the host's p2m
(&d->arch.p2m) for the macro "p2m_get_hostp2m". This macro simplifies
readability and also the differentiation between the host's p2m and
alternative p2m's, i.e., as part of the altp2m subsystem that will be
submitted in the future.

Signed-off-by: Sergej Proskurin 


Acked-by: Julien Grall 


---
Razvan Cojocaru 
Tamas K Lengyel 
Stefano Stabellini 
Julien Grall 


git send-email will do it for you if you add Cc: on each of the 4 lines 
above.


Cheers,

--
Julien Grall

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

[Xen-devel] [PATCH XTF] Implement pv_read

2017-07-17 Thread Felix Schmoll

Implement reading from PV console. Making use of polling.

Signed-off-by: Felix Schmoll 

---
This is based on the console-branch of andyhhp, so that one has to
be merged before applying this patch.
---
 common/console.c  | 27 ++-
 include/xtf/console.h |  2 ++
 2 files changed, 24 insertions(+), 5 deletions(-)

diff --git a/common/console.c b/common/console.c
index 5b4305e..66a5a06 100644
--- a/common/console.c
+++ b/common/console.c
@@ -7,6 +7,8 @@
 #include 
 #include 
 
+#include 
+
 /*
  * Output functions, registered if/when available.
  * Possibilities:
@@ -45,6 +47,24 @@ static size_t pv_console_write_some(const char *buf, size_t 
len)
 return s;
 }
 
+extern shared_info_t shared_info;
+size_t pv_console_read(char *buf, size_t len)
+{
+while ( !test_and_clear_bit(pv_evtchn, shared_info.evtchn_pending) ||
+(pv_ring->in_cons == pv_ring->in_prod ) )
+hypercall_poll(pv_evtchn);
+
+size_t s = 0;
+uint32_t cons = pv_ring->in_cons, prod = LOAD_ACQUIRE(&pv_ring->in_prod);
+
+while ( (s < len) && (0 < (prod - cons)) )
+buf[s++] = pv_ring->in[cons++ & (sizeof(pv_ring->in) - 1)];
+
+STORE_RELEASE(&pv_ring->in_cons, cons);
+
+return s;
+}
+
 /*
  * Write some data into the pv ring, synchronously waiting for all data to be
  * consumed.
@@ -70,9 +90,7 @@ static void pv_console_write(const char *buf, size_t len)
 {
 while ( ACCESS_ONCE(pv_ring->out_cons) == cons )
 {
-if ( !test_and_clear_bit(pv_evtchn,
- shared_info.evtchn_pending) )
-hypercall_poll(pv_evtchn);
+hypercall_yield();
 }
 }
 
@@ -81,8 +99,7 @@ static void pv_console_write(const char *buf, size_t len)
 /* Wait for xenconsoled to consume all the data we gave. */
 while ( ACCESS_ONCE(pv_ring->out_cons) != pv_ring->out_prod )
 {
-if ( !test_and_clear_bit(pv_evtchn, shared_info.evtchn_pending) )
-hypercall_poll(pv_evtchn);
+hypercall_yield();
 }
 }
 
diff --git a/include/xtf/console.h b/include/xtf/console.h
index 2a93c06..9b3f85d 100644
--- a/include/xtf/console.h
+++ b/include/xtf/console.h
@@ -25,6 +25,8 @@ void init_pv_console(xencons_interface_t *ring,
 void vprintk(const char *fmt, va_list args) __printf(1, 0);
 void printk(const char *fmt, ...) __printf(1, 2);
 
+size_t pv_console_read(char *buf, size_t len);
+
 #endif /* XTF_CONSOLE_H */
 
 /*
-- 
2.11.0


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

Re: [Xen-devel] [PATCH v6 03/14] arm/mem_access: Add defines supporting PTs with varying page sizes


Hi Sergej,

On 06/07/17 12:50, Sergej Proskurin wrote:

The ARMv8 architecture supports pages with different (4K, 16K, and 64K) sizes.


NIT: ARMv8 supports both AArch32 and AArch64. However, only AArch64 
supports different page granularities. To avoid confusion, please 
s/ARMv8 architecture/AArch64/



To enable guest page table walks for various configurations, this commit
extends the defines and helpers of the current implementation.

Signed-off-by: Sergej Proskurin 
---
Cc: Stefano Stabellini 
Cc: Julien Grall 
---
v3: Eliminate redundant macro definitions by introducing generic macros.

v4: Replace existing macros with ones that generate static inline
helpers as to ease the readability of the code.

Move the introduced code into lpae.h

v5: Remove PAGE_SHIFT_* defines from lpae.h as we import them now from
the header xen/lib.h.

Remove *_guest_table_offset macros as to reduce the number of
exported macros which are only used once. Instead, use the
associated functionality directly within the
GUEST_TABLE_OFFSET_HELPERS.

Add comment in GUEST_TABLE_OFFSET_HELPERS stating that a page table
with 64K page size granularity does not have a zeroeth lookup level.

Add #undefs for GUEST_TABLE_OFFSET and GUEST_TABLE_OFFSET_HELPERS.

Remove CONFIG_ARM_64 #defines.

v6: Rename *_guest_table_offset_* helpers to *_table_offset_* as they
are sufficiently generic to be applied not only to the guest's page
table walks.

Change the type of the parameter and return value of the
*_table_offset_* helpers from vaddr_t to paddr_t to enable applying
these helpers also for other purposes such as computation of IPA
offsets in second stage translation tables.
---
 xen/include/asm-arm/lpae.h | 62 ++
 1 file changed, 62 insertions(+)

diff --git a/xen/include/asm-arm/lpae.h b/xen/include/asm-arm/lpae.h
index a62b118630..f0b3d21aa7 100644
--- a/xen/include/asm-arm/lpae.h
+++ b/xen/include/asm-arm/lpae.h
@@ -3,6 +3,8 @@

 #ifndef __ASSEMBLY__

+#include 
+
 /*
  * WARNING!  Unlike the x86 pagetable code, where l1 is the lowest level and
  * l4 is the root of the trie, the ARM pagetables follow ARM's documentation:
@@ -151,6 +153,66 @@ static inline bool lpae_is_superpage(lpae_t pte, unsigned 
int level)
 return (level < 3) && lpae_mapping(pte);
 }

+/*
+ * The ARMv8 architecture supports pages with different sizes (4K, 16K, and


Same here.


+ * 64K). To enable page table walks for various configurations, the following
+ * helpers enable walking the translation table with varying page size
+ * granularities.
+ */
+
+#define LPAE_SHIFT_4K   (9)
+#define LPAE_SHIFT_16K  (11)
+#define LPAE_SHIFT_64K  (13)
+
+#define lpae_entries(gran)  (_AC(1,U) << LPAE_SHIFT_##gran)
+#define lpae_entry_mask(gran)   (lpae_entries(gran) - 1)
+
+#define third_shift(gran)   (PAGE_SHIFT_##gran)
+#define third_size(gran)((paddr_t)1 << third_shift(gran))
+
+#define second_shift(gran)  (third_shift(gran) + LPAE_SHIFT_##gran)
+#define second_size(gran)   ((paddr_t)1 << second_shift(gran))
+
+#define first_shift(gran)   (second_shift(gran) + LPAE_SHIFT_##gran)
+#define first_size(gran)((paddr_t)1 << first_shift(gran))
+
+/* Note that there is no zeroeth lookup level with a 64K granule size. */
+#define zeroeth_shift(gran) (first_shift(gran) + LPAE_SHIFT_##gran)
+#define zeroeth_size(gran)  ((paddr_t)1 << zeroeth_shift(gran))
+
+#define GUEST_TABLE_OFFSET(offs, gran)  (offs & lpae_entry_mask(gran))
+#define GUEST_TABLE_OFFSET_HELPERS(gran)   
 \


You renamed *_guest_table_offset to *_table_offset but not GUEST_TABLE_* 
one.


Please drop GUEST from both macros.

With that fixed:

Reviewed-by: Julien Grall 

Cheers,


+static inline paddr_t third_table_offset_##gran##K(paddr_t va) 
 \
+{  
 \
+return GUEST_TABLE_OFFSET((va >> third_shift(gran##K)), gran##K);  
 \
+}  
 \
+   
 \
+static inline paddr_t second_table_offset_##gran##K(paddr_t va)
 \
+{  
 \
+return GUEST_TABLE_OFFSET((va >> second_shift(gran##K)), gran##K); 
 \
+}  
 \
+   
 \
+static inline paddr_t first_table_offset_##gran##K(paddr_t va) 
 \
+{  
 \
+return GUEST_TABLE_OFFSET((va >> first_shift(gran##K)), gran##K);  
 \
+}

Re: [Xen-devel] [PATCH 1/6] xen-blkfront: quiesce/unquiesce queue instead of start/stop queues

2017-07-17 Thread Ming Lei

On Mon, Jul 17, 2017 at 12:20:56PM +0100, Roger Pau Monné wrote:
> On Sat, Jul 15, 2017 at 07:15:56AM +0800, Ming Lei wrote:
> > stopping queue may cause race and may not stop the queue really
> > after the API returns, and we have improved quiescing
> > interface and it really can block dispatching once it returns.
> > 
> > So switch to quiesce/unquiece like what we did on other drivers
> > (NVMe, NBD, mtip32xx, ...)
> > 
> > The blk_mq_stop_hw_queues() and blk_mq_start_stopped_hw_queues()
> > used in blkif_queue_rq() and blkif_interrupt() are for congestion
> > control, we leave it as it is since it is safe for this usage.
> 
> Again I yet don't understand the difference between those two, neither
> why start/stop is not fixed instead of introducing quiesce/unquiece.

There are two usages covered by start/stop now:

- congestion control for handling queue busy(BLK_STS_RESOURCE), now
only xen-blkfront and virtio-blk use that

- other usages, such as in xlvbd_release_gendisk(), for blocking
IO to driver/device

For the 1st case, it is usually fine to use stop/start

For the 2nd case, stop queue isn't enough, and we can't guarantee 
no IO is dispatched to device/driver after returning from stop queue,
for details. Most of this usage have been fixed by  Sagi Grimberg:

http://marc.info/?t=14992741596&r=1&w=2

start/stop is a bad name for 2nd usage too, what we really want
is to block IO to driver/devices, so we should use quiesce/unquiesce.

xen-blkfront is missed in Sagi's patchset which has been merged to
linus tree already, so this patch just fixes xen-blkfront simply like
other patches.

We can't use quiesce/unquiesce for replacing stop/start in the
case of BLK_STS_RESOURCE, because quiesce may sleep, and we needn't
block IO for this usage actually.

> Not to mention that start/stop is not documented, which makes all this
> even more fun.

Did you read comment of blk_mq_stop_hw_queue() and
blk_mq_stop_hw_queues() in linus tree?

> 
> Anyway I would like to ask, is the way to re-start a stopped queue the
> same way to unquiece?

I don't know what your exact question, but it is definitely that
unquiesce is counter part of quiesce, and quiesce/unquiesce doesn't
depend on 'stopped' state any more if you take a look at the code.

> 
> If not I would rather prefer that start/stop or quiece/unquiece is
> used exclusively, in order to not make the code even more complex. It

I do not think the code becomes more complex, please see the line change
of this patch:

 1 file changed, 8 insertions(+), 14 deletions(-)

then see the change of the whole patchset:

 8 files changed, 54 insertions(+), 129 deletions(-)

It is really a cleanup and simplifying.

> seems fairly easy to mess up and call "start" on a "quiesced" queue
> (or the other way around).

Definitely it shouldn't be worried because start/stop is removed
in this patchset.

-- 
Ming

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

Re: [Xen-devel] [XenSummit 2017] Notes from the PVH toolstack interface session

Andrew Cooper writes ("Re: [Xen-devel] [XenSummit 2017] Notes from the PVH 
toolstack interface session"):
> On 17/07/17 10:36, Roger Pau Monné wrote:
> > kernel = ""
> > ramdisk = ""
> > cmdline = ""
> >
> > : relative or full path in the filesystem.
> 
> Please can xl or libxl's (not entirely sure which) path handling be
> fixed as part of this work.  As noted in
> http://xenbits.xen.org/docs/xtf/index.html#errata, path handling is
> inconsistent as to whether it allows paths relative to the .cfg file. 
> All paths should support being relative to the cfg file, as that is the
> most convenient for the end user to use.

Domain config files are conventionally in /etc.  It does not make
sense to look for images there.  OTOH there should be a way to specify
a path which is relative to xl's cwd at startup.  I wouldn't mind some
kind of magic token system either, eg kernel = "%cfgdir%/image" or
soemthing, if we can agree on a syntax.

> > Boot directly into the kernel/ramdisk provided. In this case the
> > kernel must be available somewhere in the toolstack filesystem
> > hierarchy.
> >
> > firmware = "ovmf | uefi | bios | seabios | rombios | pvgrub"
> 
> What is the purpose of having uefi and bios in there?  ovmf is the uefi
> implementation, and {rom,sea}bios are the bios implementations.

See Roger's comments below.

> How does someone specify ovmf + seabios as a CSM?

EXPN CSM

> > There's no plan to support any bios or pvgrub ATM for PVH, those
> > options are simply listed for completeness. Also, generic options like
> > uefi or bios would be aliases to a concrete implementation by the
> > toolstack, ie: uefi -> ovmf, bios -> seabios most likely.
> 
> Oh - here is the reason.  -1 to this idea.  We don't want to explicitly
> let people choose options which are liable to change under their feet if
> they were to boot the same .cfg file on a newer version of Xen, as their
> VM will inevitable break.

Most VMs will not break simply if booted with a different BIOS.  Your
logic leads inevitably to the libvirt config files, which specify
things in far too much detail and cause lots of trouble.  They can be
un-portable to different versions of libvirt or qemu, let alone
different hypervisors.

> Instead of kernel= and ramdisk=, it would be better to generalise to
> something like modules=[...], perhaps with kernel being an alias for
> module[0] etc.  hvmloader already takes multiple binaries using the PVH
> module system, and PV guests are perfectly capable of multiple modules
> as well.  One specific example where an extra module would be very
> helpful is for providing the cloudinit install config file.

I don't think HVM guests can do direct boot of other than
kernel+ramdisk, can they ?

Ian.

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

[Xen-devel] A document for Xen release management

It is agreed during the summit we should write down such document. Here
is my attempt of doing so.

We should probably commit something like this into xen.git so that it
gets updated regularly.

Comments are welcome.

-

% Xen Release Management
% Wei Liu <>
% Revision 1

# Motivation

Over the years we have had different people from different company signning
up as the Release Manager of Xen. It would be rather wasteful if every new
Release Manager has to go over everything and tripped over by the same
mistakes again and again.

This file intends to document the process of managing a Xen release. It is
mainly written for Release Manager, but other roles (contributors,
maintainers and committers) are also encouraged to read this document, so
that they can have an idea what to expect from the Release Manager.

# Xen release cycle

The Xen hypervisor project now releases twice a year, at the beginning of
June and the beginning of December. The actual release date depends on a lot
of factors. 

We can roughly divide one release into two periods. The development period
and the freeze period. The former is 4 months long and the latter is about 2
months long.

During development period, contributors submit patches to be reviewed and
committed into xen.git.

During freeze period, the tree is closed for new features. Only bug fixes are
accepted. This period can be shorter or longer than 2 months. If it ends up
longer than 2 months, it eats into the next development period.

# The different roles in a Xen release

## Release Manager

A trusted developer in the community that owns the release process. The major
goal of the Release Manager is to make sure a Xen release has high quality
and doens't slip too much.

The Release Manager will not see much workload during development period, but
expects to see increasing workload during the freeze period until the final
release. He or she is expected to keep track of issues, arrange RCs,
negotiate with relevant stakeholders, balance the need from various parties
and make difficult decisions when necessary.

The Release Manager essentially owns xen-unstable branch during the freeze
period. The committers will act on the wishes of the Release Manager during
that time.

## Maintainers

A group of trusted developers who are responsible for certain components in
xen.git. They are expected to respond to patches / questions with regard to
their components in a timely manner, especially during the freeze period.

## Committers

A group of trusted maintainers who can commit to xen.git. During the
development window they normally push things as they see fit. During the
freeze period they transfer xen-unstable branch ownership and act on the
wishes of the Release Manager. That normally means they need to have an
Release Ack in order to push a patch.

## Contributors

Contributors are also expected to respond quickly to any issues regarding the
code they submitted during development period. Failing that, the Release
Manager might decide to revert the changes, declare feature unsupported or
take any action he / she deems appropriate.

## The Security Team

The Security Team operates independently. The visibility might be rather
limited due to the sensitive nature of security work. The best action the
Release Manager can take is to set aside some time for potential security
issues to be fixed.

## The Release Technician

The Release Technician is the person who tags various trees, prepares tarball
etc. He or she acts on the wishes of the Release Manager. Please make sure
the communication is as clear as it can be.

## The Community Manager

The Community Manager owns xenproject.org infrastructure. He or she is
responsible for updating various web archives, updating wiki pages and
coordinating with the PR Personnel.

## The PR Personnel

They are responsible for corrdinating with external reporters to publish Xen
release announcement. The Release Manager should be absolutely sure the
release is going out on a particular date before giving them the signal to
proceed, because there is a point of no return once they schedule a date with
external reporters.

# What happens during a release

## Development period

Send out monthly update email. The email contains the timeline of the
release, the major work items and any other information the Release Manager
sees fit. Please consider adding a recurring event to your calendar.

Occasionally check the status of the xen-unstable branch, make sure it gets
timely pushes to master.

## Freeze period

Before or at very early stage of the freeze period, agree with the Community
Manager a schedule for RC test days.

Once the freeze starts, the ownership of xen-unstable branch automatically
transfers to the Release Manager.

Here is a list of things to do for making RCs:

1. Check the status of the tree. Ask the Release Technician to make an RC if 
the tree is good.

1. Send an email to xen-devel, xen-users and xen-announce to announce the RC.

1. B

Re: [Xen-devel] [PATCH] docs: Fix the markdown for the com{1, 2} keyword command line documentation

On Mon, Jul 17, 2017 at 02:58:22PM +0100, Andrew Cooper wrote:
> No change in content.
> 
> Signed-off-by: Andrew Cooper 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v2] xenconsole: Add pipe option

Felix Schmoll writes ("[PATCH v2] xenconsole: Add pipe option"):
> Add pipe option to xenconsole that forwards console input.

Thanks.  IMO the commit message could do with better explanation.  It
should mention that xenconsole has a strange behaviour where it
doesn't forward stdin unless stdin and stdout are both ttys, and your
option is to disable this.

Also "interactive" (used in the code) is a bit of a funny name for
this, but "pipe" is worse IMO.  It would work fine for a socket (eg
from inetd), for example.  How about calling the option
"--interactive" or "--bidirectional" or something ?

The code LGTM.

Thanks,
Ian.

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

Re: [Xen-devel] [PATCH v9 7/7] tools/xen-mceinj: add support of injecting LMCE

On Mon, Jul 17, 2017 at 11:05:24AM +0100, Wei Liu wrote:
> On Thu, Jul 13, 2017 at 10:10:05AM +0800, Haozhong Zhang wrote:
> > On 07/12/17 09:26 -0400, Konrad Rzeszutek Wilk wrote:
> > > On Wed, Jul 12, 2017 at 10:04:40AM +0800, Haozhong Zhang wrote:
> > > > If option '-l' or '--lmce' is specified and the host supports LMCE,
> > > > xen-mceinj will inject LMCE to CPU specified by '-c' (or CPU0 if '-c'
> > > > is not present).
> > > > 
> > > > Signed-off-by: Haozhong Zhang 
> > > > Acked-by: Wei Liu 
> > > > ---
> > > > Cc: Ian Jackson 
> > > > Cc: Wei Liu 
> > > > ---
> > > >  tools/tests/mce-test/tools/xen-mceinj.c | 50 
> > > > +++--
> > > >  1 file changed, 48 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/tools/tests/mce-test/tools/xen-mceinj.c 
> > > > b/tools/tests/mce-test/tools/xen-mceinj.c
> > > > index bae5a46eb5..380e42190c 100644
> > > > --- a/tools/tests/mce-test/tools/xen-mceinj.c
> > > > +++ b/tools/tests/mce-test/tools/xen-mceinj.c
> > [..]
> > > >  
> > > > +static int inject_lmce(xc_interface *xc_handle, unsigned int cpu)
> > > > +{
> > > > +uint8_t *cpumap = NULL;
> > > > +size_t cpumap_size, line, shift;
> > > > +unsigned int nr_cpus;
> > > > +int ret;
> > > > +
> > > > +nr_cpus = mca_cpuinfo(xc_handle);
> > > > +if ( !nr_cpus )
> > > > +err(xc_handle, "Failed to get mca_cpuinfo");
> > > > +if ( cpu >= nr_cpus )
> > > > +err(xc_handle, "-c %u is larger than %u", cpu, nr_cpus - 1);
> > > > +
> > > > +cpumap_size = (nr_cpus + 7) / 8;
> > > 
> > > bitmap_size
> > >
> > 
> > IIUC, these bitmap_* functions/macros are libxc internals and should
> > not be used here.
> > 
> 
> Correct. Those aren't available to external users. If we want to export
> those we would need to add libxc_ prefix.

FAOD I think bitmap_* aren't appropriate to use here for the reason
stated above. That also makes the suggestion on previous patch moot. If
I hear no objection by tomorrow I will just commit these two remaining
patches.

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

Re: [Xen-devel] [XenSummit 2017] Notes from the PVH toolstack interface session

On 07/17/2017 04:08 PM, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [Xen-devel] [XenSummit 2017] Notes from the PVH 
> toolstack interface session"):
>> On 17/07/17 10:36, Roger Pau Monné wrote:
>>> kernel = ""
>>> ramdisk = ""
>>> cmdline = ""
>>>
>>> : relative or full path in the filesystem.
>>
>> Please can xl or libxl's (not entirely sure which) path handling be
>> fixed as part of this work.  As noted in
>> http://xenbits.xen.org/docs/xtf/index.html#errata, path handling is
>> inconsistent as to whether it allows paths relative to the .cfg file. 
>> All paths should support being relative to the cfg file, as that is the
>> most convenient for the end user to use.
> 
> Domain config files are conventionally in /etc.  It does not make
> sense to look for images there.

I never put them there.  But anyone who does put them there will be
using absolute paths.  Having non-absolute paths be relative to the cfg
file makes it easier for people to put config files somewhere *outside*
of /etc.

 -George

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

Re: [Xen-devel] [PATCH XTF] Implement pv_read

On Mon, Jul 17, 2017 at 12:28:20PM +0200, Felix Schmoll wrote:
> Implement reading from PV console. Making use of polling.
> 
> Signed-off-by: Felix Schmoll 
> 
> ---
> This is based on the console-branch of andyhhp, so that one has to
> be merged before applying this patch.
> ---
>  common/console.c  | 27 ++-
>  include/xtf/console.h |  2 ++
>  2 files changed, 24 insertions(+), 5 deletions(-)
> 
> diff --git a/common/console.c b/common/console.c
> index 5b4305e..66a5a06 100644
> --- a/common/console.c
> +++ b/common/console.c
> @@ -7,6 +7,8 @@
>  #include 
>  #include 
>  
> +#include 
> +
>  /*
>   * Output functions, registered if/when available.
>   * Possibilities:
> @@ -45,6 +47,24 @@ static size_t pv_console_write_some(const char *buf, 
> size_t len)
>  return s;
>  }
>  
> +extern shared_info_t shared_info;
> +size_t pv_console_read(char *buf, size_t len)
> +{
> +while ( !test_and_clear_bit(pv_evtchn, shared_info.evtchn_pending) ||
> +(pv_ring->in_cons == pv_ring->in_prod ) )

Extraneous space after in_prod.

> +hypercall_poll(pv_evtchn);
> +
> +size_t s = 0;
> +uint32_t cons = pv_ring->in_cons, prod = LOAD_ACQUIRE(&pv_ring->in_prod);

Please move the declarations to the beginning of this function.

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

Re: [Xen-devel] [PATCH v6 09/14] arm/guest_access: Move vgic_access_guest_memory to guest_access.h


Hi Sergej,

On 06/07/17 12:50, Sergej Proskurin wrote:

This commit moves the function vgic_access_guest_memory to guestcopy.c
and the header asm/guest_access.h. No functional changes are made.
Please note that the function will be renamed in the following commit.

Signed-off-by: Sergej Proskurin 


Acked-by: Julien Grall 

Cheers,


---
Cc: Stefano Stabellini 
Cc: Julien Grall 
---
v6: We added this patch to our patch series.
---
 xen/arch/arm/guestcopy.c   | 50 ++
 xen/arch/arm/vgic-v3-its.c |  1 +
 xen/arch/arm/vgic.c| 49 -
 xen/include/asm-arm/guest_access.h |  3 +++
 xen/include/asm-arm/vgic.h |  3 ---
 5 files changed, 54 insertions(+), 52 deletions(-)

diff --git a/xen/arch/arm/guestcopy.c b/xen/arch/arm/guestcopy.c
index 413125f02b..938ffe2668 100644
--- a/xen/arch/arm/guestcopy.c
+++ b/xen/arch/arm/guestcopy.c
@@ -118,6 +118,56 @@ unsigned long raw_copy_from_guest(void *to, const void 
__user *from, unsigned le
 }
 return 0;
 }
+
+/*
+ * Temporarily map one physical guest page and copy data to or from it.
+ * The data to be copied cannot cross a page boundary.
+ */
+int vgic_access_guest_memory(struct domain *d, paddr_t gpa, void *buf,
+ uint32_t size, bool is_write)
+{
+struct page_info *page;
+uint64_t offset = gpa & ~PAGE_MASK;  /* Offset within the mapped page */
+p2m_type_t p2mt;
+void *p;
+
+/* Do not cross a page boundary. */
+if ( size > (PAGE_SIZE - offset) )
+{
+printk(XENLOG_G_ERR "d%d: vITS: memory access would cross page 
boundary\n",
+   d->domain_id);
+return -EINVAL;
+}
+
+page = get_page_from_gfn(d, paddr_to_pfn(gpa), &p2mt, P2M_ALLOC);
+if ( !page )
+{
+printk(XENLOG_G_ERR "d%d: vITS: Failed to get table entry\n",
+   d->domain_id);
+return -EINVAL;
+}
+
+if ( !p2m_is_ram(p2mt) )
+{
+put_page(page);
+printk(XENLOG_G_ERR "d%d: vITS: memory used by the ITS should be RAM.",
+   d->domain_id);
+return -EINVAL;
+}
+
+p = __map_domain_page(page);
+
+if ( is_write )
+memcpy(p + offset, buf, size);
+else
+memcpy(buf, p + offset, size);
+
+unmap_domain_page(p);
+put_page(page);
+
+return 0;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index 9ef792f479..1af6820cab 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -39,6 +39,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 1e5107b9f8..7a4e3cdc88 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -638,55 +638,6 @@ void vgic_free_virq(struct domain *d, unsigned int virq)
 }

 /*
- * Temporarily map one physical guest page and copy data to or from it.
- * The data to be copied cannot cross a page boundary.
- */
-int vgic_access_guest_memory(struct domain *d, paddr_t gpa, void *buf,
- uint32_t size, bool is_write)
-{
-struct page_info *page;
-uint64_t offset = gpa & ~PAGE_MASK;  /* Offset within the mapped page */
-p2m_type_t p2mt;
-void *p;
-
-/* Do not cross a page boundary. */
-if ( size > (PAGE_SIZE - offset) )
-{
-printk(XENLOG_G_ERR "d%d: vITS: memory access would cross page 
boundary\n",
-   d->domain_id);
-return -EINVAL;
-}
-
-page = get_page_from_gfn(d, paddr_to_pfn(gpa), &p2mt, P2M_ALLOC);
-if ( !page )
-{
-printk(XENLOG_G_ERR "d%d: vITS: Failed to get table entry\n",
-   d->domain_id);
-return -EINVAL;
-}
-
-if ( !p2m_is_ram(p2mt) )
-{
-put_page(page);
-printk(XENLOG_G_ERR "d%d: vITS: memory used by the ITS should be RAM.",
-   d->domain_id);
-return -EINVAL;
-}
-
-p = __map_domain_page(page);
-
-if ( is_write )
-memcpy(p + offset, buf, size);
-else
-memcpy(buf, p + offset, size);
-
-unmap_domain_page(p);
-put_page(page);
-
-return 0;
-}
-
-/*
  * Local variables:
  * mode: C
  * c-file-style: "BSD"
diff --git a/xen/include/asm-arm/guest_access.h 
b/xen/include/asm-arm/guest_access.h
index 251e935597..49716501a4 100644
--- a/xen/include/asm-arm/guest_access.h
+++ b/xen/include/asm-arm/guest_access.h
@@ -10,6 +10,9 @@ unsigned long raw_copy_to_guest_flush_dcache(void *to, const 
void *from,
 unsigned long raw_copy_from_guest(void *to, const void *from, unsigned len);
 unsigned long raw_clear_guest(void *to, unsigned len);

+int vgic_access_guest_memory(struct domain *d, paddr_t gpa, void *buf,
+ uint32_t size, bool_t is_write);
+
 #define __raw_copy_to_guest raw_copy_to_guest
 #define __raw_copy_from_guest raw_copy_from_guest
 #define __raw_clear_guest raw_clear_g

Re: [Xen-devel] [PATCH v6 10/14] arm/guest_access: Rename vgic_access_guest_memory


Hi Sergej,

On 06/07/17 12:50, Sergej Proskurin wrote:

This commit renames the function vgic_access_guest_memory to
access_guest_memory_by_ipa. As the function name suggests, the functions
expects an ipa as argument. Thus, to make the function's purpose more


s/ipa/IPA/


clearly, we have also renamed the argument gva into ipa. All invocations


The argument is call gpa not gva. gpa stands for "Guest Physical 
Address" which is the name commonly used in Xen. IPA is the ARM naming.


So I am not convinced of the usefulness of this rename.


of this function have been adapted accordingly.

Signed-off-by: Sergej Proskurin 
---
Cc: Stefano Stabellini 
Cc: Julien Grall 
---
v6: We added this patch to our patch series.
---
 xen/arch/arm/guestcopy.c   |  8 
 xen/arch/arm/vgic-v3-its.c | 36 ++--
 xen/include/asm-arm/guest_access.h |  4 ++--
 3 files changed, 24 insertions(+), 24 deletions(-)

diff --git a/xen/arch/arm/guestcopy.c b/xen/arch/arm/guestcopy.c
index 938ffe2668..9ea8cb79a4 100644
--- a/xen/arch/arm/guestcopy.c
+++ b/xen/arch/arm/guestcopy.c
@@ -123,11 +123,11 @@ unsigned long raw_copy_from_guest(void *to, const void 
__user *from, unsigned le
  * Temporarily map one physical guest page and copy data to or from it.
  * The data to be copied cannot cross a page boundary.
  */
-int vgic_access_guest_memory(struct domain *d, paddr_t gpa, void *buf,
- uint32_t size, bool is_write)
+int access_guest_memory_by_ipa(struct domain *d, paddr_t ipa, void *buf,
+   uint32_t size, bool is_write)
 {
 struct page_info *page;
-uint64_t offset = gpa & ~PAGE_MASK;  /* Offset within the mapped page */
+uint64_t offset = ipa & ~PAGE_MASK;  /* Offset within the mapped page */
 p2m_type_t p2mt;
 void *p;

@@ -139,7 +139,7 @@ int vgic_access_guest_memory(struct domain *d, paddr_t gpa, 
void *buf,
 return -EINVAL;
 }

-page = get_page_from_gfn(d, paddr_to_pfn(gpa), &p2mt, P2M_ALLOC);
+page = get_page_from_gfn(d, paddr_to_pfn(ipa), &p2mt, P2M_ALLOC);
 if ( !page )
 {
 printk(XENLOG_G_ERR "d%d: vITS: Failed to get table entry\n",


You want to remove any mention of vITS in all the printks.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v6 11/14] arm/mem_access: Add software guest-page-table walk


Hi Sergej,

On 06/07/17 12:50, Sergej Proskurin wrote:

The function p2m_mem_access_check_and_get_page in mem_access.c
translates a gva to an ipa by means of the hardware functionality of the
ARM architecture. This is implemented in the function gva_to_ipa. If
mem_access is active, hardware-based gva to ipa translation might fail,
as gva_to_ipa uses the guest's translation tables, access to which might
be restricted by the active VTTBR. To address this issue, in this commit
we add a software-based guest-page-table walk, which will be used by the
function p2m_mem_access_check_and_get_page perform the gva to ipa
translation in software in one of the following commits.

Note: The introduced function guest_walk_tables assumes that the domain,
the gva of which is to be translated, is running on the currently active
vCPU. To walk the guest's page tables on a different vCPU, the following
registers would need to be loaded: TCR_EL1, TTBR0_EL1, TTBR1_EL1, and
SCTLR_EL1.

Signed-off-by: Sergej Proskurin 


Acked-by: Julien Grall 

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 1/6] xen-blkfront: quiesce/unquiesce queue instead of start/stop queues

On Mon, Jul 17, 2017 at 11:06:28PM +0800, Ming Lei wrote:
> On Mon, Jul 17, 2017 at 12:20:56PM +0100, Roger Pau Monné wrote:
> > On Sat, Jul 15, 2017 at 07:15:56AM +0800, Ming Lei wrote:
> > > stopping queue may cause race and may not stop the queue really
> > > after the API returns, and we have improved quiescing
> > > interface and it really can block dispatching once it returns.
> > > 
> > > So switch to quiesce/unquiece like what we did on other drivers
> > > (NVMe, NBD, mtip32xx, ...)
> > > 
> > > The blk_mq_stop_hw_queues() and blk_mq_start_stopped_hw_queues()
> > > used in blkif_queue_rq() and blkif_interrupt() are for congestion
> > > control, we leave it as it is since it is safe for this usage.
> > 
> > Again I yet don't understand the difference between those two, neither
> > why start/stop is not fixed instead of introducing quiesce/unquiece.
> 
> There are two usages covered by start/stop now:
> 
> - congestion control for handling queue busy(BLK_STS_RESOURCE), now
> only xen-blkfront and virtio-blk use that
> 
> - other usages, such as in xlvbd_release_gendisk(), for blocking
> IO to driver/device
> 
> For the 1st case, it is usually fine to use stop/start
> 
> For the 2nd case, stop queue isn't enough, and we can't guarantee 
> no IO is dispatched to device/driver after returning from stop queue,
> for details. Most of this usage have been fixed by  Sagi Grimberg:

OK, so basically after calling stop the queue might still be running.

> We can't use quiesce/unquiesce for replacing stop/start in the
> case of BLK_STS_RESOURCE, because quiesce may sleep, and we needn't
> block IO for this usage actually.

Do you mean that quiesce/unquiesce cannot be used while holding a
spinlock?

> 
> > Not to mention that start/stop is not documented, which makes all this
> > even more fun.
> 
> Did you read comment of blk_mq_stop_hw_queue() and
> blk_mq_stop_hw_queues() in linus tree?

OK, this has been added very recently.

> > 
> > Anyway I would like to ask, is the way to re-start a stopped queue the
> > same way to unquiece?
> 
> I don't know what your exact question, but it is definitely that
> unquiesce is counter part of quiesce, and quiesce/unquiesce doesn't
> depend on 'stopped' state any more if you take a look at the code.
> 
> > 
> > If not I would rather prefer that start/stop or quiece/unquiece is
> > used exclusively, in order to not make the code even more complex. It
> 
> I do not think the code becomes more complex, please see the line change
> of this patch:

Before this patch blkfront used:
blk_mq_stop_hw_queues
blk_mq_start_stopped_hw_queues
blk_mq_kick_requeue_list

After the patch it uses:
blk_mq_quiesce_queue
blk_mq_unquiesce_queue
blk_mq_stop_hw_queues
blk_mq_start_stopped_hw_queues
blk_mq_kick_requeue_list
blk_mq_run_hw_queues

It's not about line changes, but the amount of interfaces blkfront has
to use. Apart from introducing the quiesce/unquiesce, you also
introduce a call to blk_mq_run_hw_queues, which is not documented in
the commit message.

> > seems fairly easy to mess up and call "start" on a "quiesced" queue
> > (or the other way around).
> 
> Definitely it shouldn't be worried because start/stop is removed
> in this patchset.

Hm, how is that? I haven't seen any patch to blkfront to remove the
usage of start/stop, am I missing something?

Roger.

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

Re: [Xen-devel] [PATCH v6 12/14] arm/mem_access: Add long-descriptor based gpt


Hi Sergej,

On 06/07/17 12:50, Sergej Proskurin wrote:

+/*
+ * Get the MSB number of the GVA, according to "AddrTop" pseudocode
+ * implementation in ARM DDI 0487B.a J1-6066.
+ */
+static unsigned int get_top_bit(struct domain *d, vaddr_t gva, register_t tcr)
+{
+unsigned int topbit;
+
+/*
+ * IF EL1 is using AArch64 then addresses from EL0 using AArch32 are


NIT: s/IF/If/


+ * zero-extended to 64 bits (ARM DDI 0487B.a J1-6066).
+ */
+if ( is_32bit_domain(d) )
+topbit = 31;
+else if ( is_64bit_domain(d) )
+{
+if ( ((gva & BIT_ULL(55)) && (tcr & TCR_EL1_TBI1)) ||
+ (!(gva & BIT_ULL(55)) && (tcr & TCR_EL1_TBI0)) )
+topbit = 55;
+else
+topbit = 63;
+}
+
+return topbit;
+}
+
+/* Make sure the base address does not exceed its configured size. */
+static int check_base_size(unsigned int output_size, uint64_t base)
+{
+paddr_t mask = GENMASK_ULL((TCR_EL1_IPS_48_BIT_VAL - 1), output_size);
+
+if ( (output_size < TCR_EL1_IPS_48_BIT_VAL) && (base & mask) )
+return -EFAULT;
+
+return 0;


This function only return 0 or -EFAULT and the caller doesn't care of 
the exact value. I would prefer if you return a boolean here.


[...]


+/*
+ * According to to ARM DDI 0487B.a J1-5927, we return an error if the found
+ * PTE is invalid or holds a reserved entry (PTE<1:0> == x0)) or if the PTE
+ * maps a memory block at level 3 (PTE<1:0> == 01).
+ */
+if ( !lpae_is_page(pte, level) && !lpae_is_superpage(pte, level) )
+return -EFAULT;
+
+*ipa = pfn_to_paddr(pte.walk.base) | (gva & masks[gran][level]);


I haven't noticed it until now. When using 16KB and 64KB, you rely on 
the bottom bits to be zeroed. Although, the guest could purposefully put 
wrong value here. So you want to mask it as you do just above.


Furthermore, as other part of the Xen ARM you rely on the page size of 
Xen to always be 4KB. This is not really true and this code will break 
as soon as we introduce 16KB/64KB page granularity support in Xen. I 
will have a look on what to do here. No need to worry about that for now.



+
+/*
+ * Set permissions so that the caller can check the flags by herself. Note
+ * that stage 1 translations also inherit attributes from the tables
+ * (ARM DDI 0487B.a J1-5928).
+ */
+if ( !pte.pt.ro && !ro_table )
+*perms |= GV2M_WRITE;
+if ( !pte.pt.xn && !xn_table )
+*perms |= GV2M_EXEC;
+
+return 0;
 }

 int guest_walk_tables(const struct vcpu *v, vaddr_t gva,



Cheers,

--
Julien Grall

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

Re: [Xen-devel] ARM: Adjusting guest memory size through xl mem-{set|max} fails

2017-07-17 Thread Sergej Proskurin

Hi Julien,


On 07/17/2017 03:53 PM, Julien Grall wrote:
> (+Wei and Ian)
>
> Hi Sergej
>
> On 17/07/17 13:04, Sergej Proskurin wrote:
>> Hi all,
>>
>> My setup comprises an ARMv7 (Arndale, Linux kernel v4.11.6) and an ARMv8
>> (LeMaker HiKey, Linux kernel v4.9.0) development board. On both boards,
>> I have Xen version 4.10-unstable running with the associated tools to
>> manage a domu.
>>
>> Currently, I am trying to get xl mem-{set|max} to work on both
>> architectures. Unfortunately, both command invocations fail with the
>> following message (I remember using xl mem-{set|max} on ARMv7 before
>> with Xen version 4.7 and 4.8):
>>
>> ---
>> xl: libxl.c:339: libxl_defbool_val: Assertion
>> `!libxl_defbool_is_default(db)' failed.
>> Aborted
>> ---
>
> I haven't myself tried to use xl mem-{set|max}. Looking at the assert,
> you hit because a boolean is not initialized. It would be interesting
> to know which one.
>
> I have CCed the tools maintainers to get more feedback.
>
> Cheers,
>

Thank you. That is already a great help!

>>
>> The domu is created with the following parameters:
>>
>> ---
>> kernel= "/boot/zImage"
>> name = "domu"
>> memory = 512
>> vcpus = 2
>> disk=[ 'phy:/dev/vg0/VG0, xvda,w' ]
>> extra = 'console=hvc0 xencons=tty root=/dev/xvda rw'
>> ---
>>
>> My Kernel versions have CONFIG_XEN_BALLOON flag set (see ARMv7 example
>> Linux .config below).
>>
>> ---
>> $ cat .config | grep -i XEN
>> CONFIG_XEN_DOM0=y
>> CONFIG_XEN=y
>> CONFIG_XEN_BLKDEV_FRONTEND=y
>> CONFIG_XEN_BLKDEV_BACKEND=y
>> # CONFIG_XEN_SCSI_FRONTEND is not set
>> CONFIG_XEN_NETDEV_FRONTEND=y
>> CONFIG_XEN_NETDEV_BACKEND=y
>> CONFIG_INPUT_XEN_KBDDEV_FRONTEND=y
>> CONFIG_HVC_XEN=y
>> CONFIG_HVC_XEN_FRONTEND=y
>> # CONFIG_TCG_XEN is not set
>> # CONFIG_XEN_WDT is not set
>> CONFIG_XEN_FBDEV_FRONTEND=y
>> # Xen driver support
>> CONFIG_XEN_BALLOON=y
>> CONFIG_XEN_SCRUB_PAGES=y
>> CONFIG_XEN_DEV_EVTCHN=y
>> CONFIG_XEN_BACKEND=y
>> CONFIG_XENFS=y
>> CONFIG_XEN_COMPAT_XENFS=y
>> CONFIG_XEN_SYS_HYPERVISOR=y
>> CONFIG_XEN_XENBUS_FRONTEND=y
>> CONFIG_XEN_GNTDEV=m
>> CONFIG_XEN_GRANT_DEV_ALLOC=m
>> CONFIG_SWIOTLB_XEN=y
>> CONFIG_XEN_PRIVCMD=y
>> CONFIG_XEN_AUTO_XLATE=y
>> ---
>>
>> Besides, I can see in the dmesg output that the balloon driver gets
>> initialized:
>>
>> ---
>> # dmesg | grep -i balloon
>> [0.180942] xen:balloon: Initialising balloon driver
>> [0.187103] xen_balloon: Initialising balloon driver
>> ---
>>
>> It would be great if someone would help me to resolve this issue as I am
>> obviously missing something. Thank you very much in advance.
>>
>> Best regards,
>> ~Sergej
>>
>>
>> ___
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> https://lists.xen.org/xen-devel
>>
>

Cheers,
~Sergej

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

[Xen-devel] [linux-linus test] 111900: regressions - trouble: broken/fail/pass

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

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 7 xen-boot fail REGR. 
vs. 110515
 test-amd64-amd64-i386-pvgrub  7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-xl-pvh-intel  7 xen-bootfail REGR. vs. 110515
 test-amd64-amd64-qemuu-nested-intel  7 xen-boot  fail REGR. vs. 110515
 test-amd64-amd64-xl-qcow2 7 xen-boot fail REGR. vs. 110515
 test-amd64-i386-libvirt-xsm  16 guest-saverestore.2  fail REGR. vs. 110515
 test-amd64-amd64-amd64-pvgrub  7 xen-bootfail REGR. vs. 110515
 test-amd64-amd64-xl  16 guest-localmigrate   fail REGR. vs. 110515
 test-amd64-amd64-xl-xsm  16 guest-localmigrate   fail REGR. vs. 110515
 test-amd64-amd64-libvirt 16 guest-saverestore.2  fail REGR. vs. 110515
 test-amd64-amd64-xl-credit2  15 guest-saverestorefail REGR. vs. 110515
 test-amd64-i386-xl   16 guest-localmigrate   fail REGR. vs. 110515
 test-amd64-amd64-libvirt-pair 21 guest-start/debian  fail REGR. vs. 110515
 test-amd64-i386-libvirt  10 debian-install   fail REGR. vs. 110515
 test-amd64-amd64-xl-multivcpu 15 guest-saverestore   fail REGR. vs. 110515
 test-amd64-amd64-pair21 guest-start/debian   fail REGR. vs. 110515
 test-amd64-amd64-libvirt-xsm 16 guest-saverestore.2  fail REGR. vs. 110515
 test-amd64-i386-xl-xsm   16 guest-localmigrate   fail REGR. vs. 110515
 test-amd64-amd64-xl-pvh-amd  16 guest-localmigrate   fail REGR. vs. 110515
 test-amd64-i386-libvirt-pair 21 guest-start/debian   fail REGR. vs. 110515
 test-amd64-i386-pair 21 guest-start/debian   fail REGR. vs. 110515
 test-amd64-amd64-pygrub   7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-xl-qemut-debianhvm-amd64  7 xen-bootfail REGR. vs. 110515
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
110515
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
110515

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumprun-amd64  4 host-install(4) broken blocked in 110515
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 110515
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 110515
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 110515
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 110515
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 110515
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 110515
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 110515
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-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-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check

Re: [Xen-devel] [PATCH v6 13/14] arm/mem_access: Add short-descriptor based gpt


Hi Sergej,

On 06/07/17 12:50, Sergej Proskurin wrote:

This commit adds functionality to walk the guest's page tables using the
short-descriptor translation table format for both ARMv7 and ARMv8. The
implementation is based on ARM DDI 0487B-a J1-6002 and ARM DDI 0406C-b
B3-1506.

Signed-off-by: Sergej Proskurin 


Acked-by: Julien Grall 

Cheers,

--
Julien Grall

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

[Xen-devel] [PATCH v4] x86/monitor: Notify monitor if an emulation fails.

2017-07-17 Thread Petre Pircalabu

If case of a vm_event with the emulate_flags set, if the instruction
cannot be emulated, the monitor should be notified instead of directly
injecting a hw exception.
This behavior can be used to re-execute an instruction not supported by
the emulator using the real processor (e.g. altp2m) instead of just
crashing.

Signed-off-by: Petre Pircalabu 

---
Changed since v1:
  * Removed the emulation kind check when calling hvm_inject_hw_exception

Changed since v2:
  * Removed a file added by mistake

Changed since v3:
  * Removed extra stray line
  * Added the _enabled suffix to the emul_unhandleable monitor option

Changed since v4
  * Fixed return expression of hvm_monitor_emul_unhandleable handle
  monitor_traps failures.
  * Removed stray parantheses.
---
 tools/libxc/include/xenctrl.h |  2 ++
 tools/libxc/xc_monitor.c  | 14 ++
 xen/arch/x86/hvm/emulate.c|  7 ++-
 xen/arch/x86/hvm/monitor.c| 17 +
 xen/arch/x86/monitor.c| 12 
 xen/include/asm-x86/domain.h  |  1 +
 xen/include/asm-x86/hvm/monitor.h |  1 +
 xen/include/asm-x86/monitor.h |  3 ++-
 xen/include/public/domctl.h   |  1 +
 xen/include/public/vm_event.h |  2 ++
 10 files changed, 58 insertions(+), 2 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index c51bb3b..8deb5ac 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2029,6 +2029,8 @@ int xc_monitor_debug_exceptions(xc_interface *xch, 
domid_t domain_id,
 int xc_monitor_cpuid(xc_interface *xch, domid_t domain_id, bool enable);
 int xc_monitor_privileged_call(xc_interface *xch, domid_t domain_id,
bool enable);
+int xc_monitor_emul_unhandleable(xc_interface *xch, domid_t domain_id,
+ bool enable);
 /**
  * This function enables / disables emulation for each REP for a
  * REP-compatible instruction.
diff --git a/tools/libxc/xc_monitor.c b/tools/libxc/xc_monitor.c
index b44ce93..8e72c6c 100644
--- a/tools/libxc/xc_monitor.c
+++ b/tools/libxc/xc_monitor.c
@@ -216,6 +216,20 @@ int xc_monitor_privileged_call(xc_interface *xch, domid_t 
domain_id,
 return do_domctl(xch, &domctl);
 }
 
+int xc_monitor_emul_unhandleable(xc_interface *xch, domid_t domain_id,
+ bool enable)
+{
+DECLARE_DOMCTL;
+
+domctl.cmd = XEN_DOMCTL_monitor_op;
+domctl.domain = domain_id;
+domctl.u.monitor_op.op = enable ? XEN_DOMCTL_MONITOR_OP_ENABLE
+: XEN_DOMCTL_MONITOR_OP_DISABLE;
+domctl.u.monitor_op.event = XEN_DOMCTL_MONITOR_EVENT_EMUL_UNHANDLEABLE;
+
+return do_domctl(xch, &domctl);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index b2068ad..e1177f8 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -14,12 +14,14 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -2104,7 +2106,10 @@ void hvm_emulate_one_vm_event(enum emul_kind kind, 
unsigned int trapnr,
 return;
 case X86EMUL_UNHANDLEABLE:
 hvm_dump_emulation_state(XENLOG_G_DEBUG, "Mem event", &ctx);
-hvm_inject_hw_exception(trapnr, errcode);
+if ( hvm_monitor_emul_unhandleable() )
+return;
+else
+hvm_inject_hw_exception(trapnr, errcode);
 break;
 case X86EMUL_EXCEPTION:
 hvm_inject_event(&ctx.ctxt.event);
diff --git a/xen/arch/x86/hvm/monitor.c b/xen/arch/x86/hvm/monitor.c
index a7ccfc4..e77b05e 100644
--- a/xen/arch/x86/hvm/monitor.c
+++ b/xen/arch/x86/hvm/monitor.c
@@ -57,6 +57,23 @@ bool_t hvm_monitor_cr(unsigned int index, unsigned long 
value, unsigned long old
 return 0;
 }
 
+bool hvm_monitor_emul_unhandleable(void)
+{
+struct vcpu *curr = current;
+
+/*
+ * Send a vm_event to the monitor to signal that the current
+ * instruction couldn't be emulated.
+ */
+vm_event_request_t req = {
+.reason = VM_EVENT_REASON_EMUL_UNHANDLEABLE,
+.vcpu_id  = curr->vcpu_id,
+};
+
+return curr->domain->arch.monitor.emul_unhandleable_enabled &&
+monitor_traps(curr, true, &req) == 1;
+}
+
 void hvm_monitor_msr(unsigned int msr, uint64_t value)
 {
 struct vcpu *curr = current;
diff --git a/xen/arch/x86/monitor.c b/xen/arch/x86/monitor.c
index 706454f..f791372 100644
--- a/xen/arch/x86/monitor.c
+++ b/xen/arch/x86/monitor.c
@@ -283,6 +283,18 @@ int arch_monitor_domctl_event(struct domain *d,
 break;
 }
 
+case XEN_DOMCTL_MONITOR_EVENT_EMUL_UNHANDLEABLE:
+{
+bool old_status = ad->monitor.emul_unhandleable_enabled;
+if ( unlikely(old_status == requested_status) )
+return -EEXIST;
+
+domain_pause(d);
+ad->monitor.emul_unhandleable_enabled = requested_status;
+

Re: [Xen-devel] [PATCH 02/25 v6] xen/arm: vpl011: Add SBSA UART emulation in Xen


Hi Bhupinder,

On 17/07/17 14:06, Bhupinder Thakur wrote:

Add emulation code to emulate read/write access to pl011 registers
and pl011 interrupts:

- Emulate DR read/write by reading and writing from/to the IN
  and OUT ring buffers and raising an event to the backend when
  there is data in the OUT ring buffer and injecting an interrupt
  to the guest when there is data in the IN ring buffer

- Other registers are related to interrupt management and
  essentially control when interrupts are delivered to the guest

This patch implements the SBSA Generic UART which is a subset of ARM
PL011 UART.

The SBSA Generic UART is covered in Appendix B of
https://static.docs.arm.com/den0029/a/Server_Base_System_Architecture_v3_1_ARM_DEN_0029A.pdf

Signed-off-by: Bhupinder Thakur 


Acked-by: Julien Grall 

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 05/25 v6] xen/arm: vpl011: Rearrange xen header includes in alphabetical order in domctl.c


Hi Bhupinder,

On 17/07/17 14:06, Bhupinder Thakur wrote:

Rearrange xen header includes in alphabetical order in domctl.c.

Signed-off-by: Bhupinder Thakur 
Reviewed-by: Stefano Stabellini 


For the future, please mention if you keep a reviewed-by tag when you 
modify a patch. This will give a chance to the reviewer to 
agree/disagree on the change.


Reviewed-by: Julien Grall 

Cheers,

--
Julien Grall

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

[Xen-devel] [qemu-mainline bisection] complete test-amd64-i386-xl-qemuu-win7-amd64

branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemuu-win7-amd64
testid windows-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://git.qemu.org/qemu.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  qemuu git://git.qemu.org/qemu.git
  Bug introduced:  04bf2526ce87f21b32c9acba1c5518708c243ad0
  Bug not present: 1a29cc8f5ebd657e159dbe4be340102595846d42
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/111933/


  commit 04bf2526ce87f21b32c9acba1c5518708c243ad0
  Author: Prasad J Pandit 
  Date:   Wed Jul 12 18:08:40 2017 +0530
  
  exec: use qemu_ram_ptr_length to access guest ram
  
  When accessing guest's ram block during DMA operation, use
  'qemu_ram_ptr_length' to get ram block pointer. It ensures
  that DMA operation of given length is possible; And avoids
  any OOB memory access situations.
  
  Reported-by: Alex 
  Signed-off-by: Prasad J Pandit 
  Message-Id: <20170712123840.29328-1-ppan...@redhat.com>
  Signed-off-by: Paolo Bonzini 


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/qemu-mainline/test-amd64-i386-xl-qemuu-win7-amd64.windows-install.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/qemu-mainline/test-amd64-i386-xl-qemuu-win7-amd64.windows-install
 --summary-out=tmp/111933.bisection-summary --basis-template=111765 
--blessings=real,real-bisect qemu-mainline test-amd64-i386-xl-qemuu-win7-amd64 
windows-install
Searching for failure / basis pass:
 111889 fail [host=fiano0] / 111790 ok.
Failure / basis pass flights: 111889 / 111790
(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://git.qemu.org/qemu.git
Tree: xen git://xenbits.xen.org/xen.git
Latest b65f2f457c49b2cfd7967c34b7a0b04c25587f13 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
8051789e982499050680a26febeada7467e18a8d 
4871b51b9241b10f4fd8e04bbb21577886795e25 
614a14736e33fb84872eb00f08799ebbc73a96c6
Basis pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
8051789e982499050680a26febeada7467e18a8d 
49bcce4b9c11759678fd223aefb48691c4959d4f 
614a14736e33fb84872eb00f08799ebbc73a96c6
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/linux-pvops.git#b65f2f457c49b2cfd7967c34b7a0b04c25587f13-b65f2f457c49b2cfd7967c34b7a0b04c25587f13
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://xenbits.xen.org/qemu-xen-traditional.git#8051789e982499050680a26febeada7467e18a8d-8051789e982499050680a26febeada7467e18a8d
 
git://git.qemu.org/qemu.git#49bcce4b9c11759678fd223aefb48691c4959d4f-4871b51b9241b10f4fd8e04bbb21577886795e25
 
git://xenbits.xen.org/xen.git#614a14736e33fb84872eb00f08799ebbc73a96c6-614a14736e33fb84872eb00f08799ebbc73a96c6
From git://cache:9419/git://git.qemu.org/qemu
   77031ee..3408d5a  master -> origin/master
Loaded 1006 nodes in revision graph
Searching for test results:
 111790 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
8051789e982499050680a26febeada7467e18a8d 
49bcce4b9c11759678fd223aefb48691c4959d4f 
614a14736e33fb84872eb00f08799ebbc73a96c6
 111817 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
8051789e982499050680a26febeada7467e18a8d 
4871b51b9241b10f4fd8e04bbb21577886795e25 
614a14736e33fb84872eb00f08799ebbc73a96c6
 111862 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
8051789e982499050680a26febeada7467e18a8d 
49bcce4b9c11759678fd223aefb48691c4959d4f 
614a14736e33fb84872eb00f08799ebbc73a96c6
 111871 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
8051789e982499050680a26febeada7467e18a8d 
4871b51b9241b10f4fd8e04bbb21577886795e25 
614a14736e33fb84872eb00f08799ebbc73a96c6
 111848 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
8051789e982499050680a26febeada7467e18a8d 
4871b51b9241b10f4fd8e04bbb21577886795e25 
614a14736e33fb84872eb00f08799ebbc73a96c6
 111876 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
8051789e982499050680a26febeada7467e18a8d 
6c6076662d98c068059983d411cb2a8987ba5670 
614a14736e33fb84872eb00f08799ebbc73a96c6
 111929 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
8051789e98249

[Xen-devel] [PATCH v5] x86/monitor: Notify monitor if an emulation fails.

2017-07-17 Thread Petre Pircalabu

If case of a vm_event with the emulate_flags set, if the instruction
cannot be emulated, the monitor should be notified instead of directly
injecting a hw exception.
This behavior can be used to re-execute an instruction not supported by
the emulator using the real processor (e.g. altp2m) instead of just
crashing.

Signed-off-by: Petre Pircalabu 

---
Changed since v1:
  * Removed the emulation kind check when calling hvm_inject_hw_exception

Changed since v2:
  * Removed a file added by mistake

Changed since v3:
  * Removed extra stray line
  * Added the _enabled suffix to the emul_unhandleable monitor option

Changed since v4
  * Fixed return expression of hvm_monitor_emul_unhandleable handle
  monitor_traps failures.
  * Removed stray parantheses.
---
 tools/libxc/include/xenctrl.h |  2 ++
 tools/libxc/xc_monitor.c  | 14 ++
 xen/arch/x86/hvm/emulate.c|  7 ++-
 xen/arch/x86/hvm/monitor.c| 17 +
 xen/arch/x86/monitor.c| 12 
 xen/include/asm-x86/domain.h  |  1 +
 xen/include/asm-x86/hvm/monitor.h |  1 +
 xen/include/asm-x86/monitor.h |  3 ++-
 xen/include/public/domctl.h   |  1 +
 xen/include/public/vm_event.h |  2 ++
 10 files changed, 58 insertions(+), 2 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index c51bb3b..8deb5ac 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2029,6 +2029,8 @@ int xc_monitor_debug_exceptions(xc_interface *xch, 
domid_t domain_id,
 int xc_monitor_cpuid(xc_interface *xch, domid_t domain_id, bool enable);
 int xc_monitor_privileged_call(xc_interface *xch, domid_t domain_id,
bool enable);
+int xc_monitor_emul_unhandleable(xc_interface *xch, domid_t domain_id,
+ bool enable);
 /**
  * This function enables / disables emulation for each REP for a
  * REP-compatible instruction.
diff --git a/tools/libxc/xc_monitor.c b/tools/libxc/xc_monitor.c
index b44ce93..8e72c6c 100644
--- a/tools/libxc/xc_monitor.c
+++ b/tools/libxc/xc_monitor.c
@@ -216,6 +216,20 @@ int xc_monitor_privileged_call(xc_interface *xch, domid_t 
domain_id,
 return do_domctl(xch, &domctl);
 }
 
+int xc_monitor_emul_unhandleable(xc_interface *xch, domid_t domain_id,
+ bool enable)
+{
+DECLARE_DOMCTL;
+
+domctl.cmd = XEN_DOMCTL_monitor_op;
+domctl.domain = domain_id;
+domctl.u.monitor_op.op = enable ? XEN_DOMCTL_MONITOR_OP_ENABLE
+: XEN_DOMCTL_MONITOR_OP_DISABLE;
+domctl.u.monitor_op.event = XEN_DOMCTL_MONITOR_EVENT_EMUL_UNHANDLEABLE;
+
+return do_domctl(xch, &domctl);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index b2068ad..e1177f8 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -14,12 +14,14 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -2104,7 +2106,10 @@ void hvm_emulate_one_vm_event(enum emul_kind kind, 
unsigned int trapnr,
 return;
 case X86EMUL_UNHANDLEABLE:
 hvm_dump_emulation_state(XENLOG_G_DEBUG, "Mem event", &ctx);
-hvm_inject_hw_exception(trapnr, errcode);
+if ( hvm_monitor_emul_unhandleable() )
+return;
+else
+hvm_inject_hw_exception(trapnr, errcode);
 break;
 case X86EMUL_EXCEPTION:
 hvm_inject_event(&ctx.ctxt.event);
diff --git a/xen/arch/x86/hvm/monitor.c b/xen/arch/x86/hvm/monitor.c
index a7ccfc4..e77b05e 100644
--- a/xen/arch/x86/hvm/monitor.c
+++ b/xen/arch/x86/hvm/monitor.c
@@ -57,6 +57,23 @@ bool_t hvm_monitor_cr(unsigned int index, unsigned long 
value, unsigned long old
 return 0;
 }
 
+bool hvm_monitor_emul_unhandleable(void)
+{
+struct vcpu *curr = current;
+
+/*
+ * Send a vm_event to the monitor to signal that the current
+ * instruction couldn't be emulated.
+ */
+vm_event_request_t req = {
+.reason = VM_EVENT_REASON_EMUL_UNHANDLEABLE,
+.vcpu_id  = curr->vcpu_id,
+};
+
+return curr->domain->arch.monitor.emul_unhandleable_enabled &&
+monitor_traps(curr, true, &req) == 1;
+}
+
 void hvm_monitor_msr(unsigned int msr, uint64_t value)
 {
 struct vcpu *curr = current;
diff --git a/xen/arch/x86/monitor.c b/xen/arch/x86/monitor.c
index 706454f..f791372 100644
--- a/xen/arch/x86/monitor.c
+++ b/xen/arch/x86/monitor.c
@@ -283,6 +283,18 @@ int arch_monitor_domctl_event(struct domain *d,
 break;
 }
 
+case XEN_DOMCTL_MONITOR_EVENT_EMUL_UNHANDLEABLE:
+{
+bool old_status = ad->monitor.emul_unhandleable_enabled;
+if ( unlikely(old_status == requested_status) )
+return -EEXIST;
+
+domain_pause(d);
+ad->monitor.emul_unhandleable_enabled = requested_status;
+

Re: [Xen-devel] A document for Xen release management

On 17/07/17 17:09, Wei Liu wrote:
> It is agreed during the summit we should write down such document. Here
> is my attempt of doing so.
> 
> We should probably commit something like this into xen.git so that it
> gets updated regularly.
> 
> Comments are welcome.
> 
> -
> 
> % Xen Release Management
> % Wei Liu <>
> % Revision 1
> 
> # Motivation
> 
> Over the years we have had different people from different company signning

signing

> up as the Release Manager of Xen. It would be rather wasteful if every new
> Release Manager has to go over everything and tripped over by the same
> mistakes again and again.
> 
> This file intends to document the process of managing a Xen release. It is
> mainly written for Release Manager, but other roles (contributors,
> maintainers and committers) are also encouraged to read this document, so
> that they can have an idea what to expect from the Release Manager.
> 
> # Xen release cycle
> 
> The Xen hypervisor project now releases twice a year, at the beginning of
> June and the beginning of December. The actual release date depends on a lot
> of factors. 
> 
> We can roughly divide one release into two periods. The development period
> and the freeze period. The former is 4 months long and the latter is about 2
> months long.
> 
> During development period, contributors submit patches to be reviewed and
> committed into xen.git.
> 
> During freeze period, the tree is closed for new features. Only bug fixes are
> accepted. This period can be shorter or longer than 2 months. If it ends up
> longer than 2 months, it eats into the next development period.
> 
> # The different roles in a Xen release
> 
> ## Release Manager
> 
> A trusted developer in the community that owns the release process. The major
> goal of the Release Manager is to make sure a Xen release has high quality
> and doens't slip too much.
> 
> The Release Manager will not see much workload during development period, but
> expects to see increasing workload during the freeze period until the final
> release. He or she is expected to keep track of issues, arrange RCs,
> negotiate with relevant stakeholders, balance the need from various parties
> and make difficult decisions when necessary.
> 
> The Release Manager essentially owns xen-unstable branch during the freeze
> period. The committers will act on the wishes of the Release Manager during
> that time.
> 
> ## Maintainers
> 
> A group of trusted developers who are responsible for certain components in
> xen.git. They are expected to respond to patches / questions with regard to
> their components in a timely manner, especially during the freeze period.
> 
> ## Committers
> 
> A group of trusted maintainers who can commit to xen.git. During the
> development window they normally push things as they see fit. During the
> freeze period they transfer xen-unstable branch ownership and act on the
> wishes of the Release Manager. That normally means they need to have an
> Release Ack in order to push a patch.
> 
> ## Contributors
> 
> Contributors are also expected to respond quickly to any issues regarding the
> code they submitted during development period. Failing that, the Release
> Manager might decide to revert the changes, declare feature unsupported or
> take any action he / she deems appropriate.
> 
> ## The Security Team
> 
> The Security Team operates independently. The visibility might be rather
> limited due to the sensitive nature of security work. The best action the
> Release Manager can take is to set aside some time for potential security
> issues to be fixed.
> 
> ## The Release Technician
> 
> The Release Technician is the person who tags various trees, prepares tarball
> etc. He or she acts on the wishes of the Release Manager. Please make sure
> the communication is as clear as it can be.
> 
> ## The Community Manager
> 
> The Community Manager owns xenproject.org infrastructure. He or she is
> responsible for updating various web archives, updating wiki pages and
> coordinating with the PR Personnel.
> 
> ## The PR Personnel
> 
> They are responsible for corrdinating with external reporters to publish Xen

coordinating

> release announcement. The Release Manager should be absolutely sure the
> release is going out on a particular date before giving them the signal to
> proceed, because there is a point of no return once they schedule a date with
> external reporters.
> 
> # What happens during a release
> 
> ## Development period
> 
> Send out monthly update email. The email contains the timeline of the
> release, the major work items and any other information the Release Manager
> sees fit. Please consider adding a recurring event to your calendar.
> 
> Occasionally check the status of the xen-unstable branch, make sure it gets
> timely pushes to master.
> 
> ## Freeze period
> 
> Before or at very early stage of the freeze period, agree with the Community
> Manager a schedule for RC test days.
> 
> Once the freeze starts, the

Re: [Xen-devel] [PATCH 06/25 v6] xen/arm: vpl011: Add a new domctl API to initialize vpl011


Hi Bhupinder,

On 17/07/17 14:06, Bhupinder Thakur wrote:

Add a new domctl API to initialize vpl011. It takes the GFN and console
backend domid as input and returns an event channel to be used for
sending and receiving events from Xen.

Xen will communicate with xenconsole using GFN as the ring buffer and
the event channel to transmit and receive pl011 data on the guest domain's
behalf.

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

Changes since v5:
- xc_dom_vpl011_init() will be compiled for both x86/arm architectures as there
  is nothing architecture specific in this function. This function will return
  error when called for x86.
- Fixed coding style issues in libxl.

Changes since v4:
- Removed libxl__arch_domain_create_finish().
- Added a new function libxl__arch_build_dom_finish(), which is called at the 
last
  in libxl__build_dom(). This function calls the vpl011 initialization function 
now.

Changes since v3:
- Added a new arch specific function libxl__arch_domain_create_finish(), which
  calls the vpl011 initialization function. For x86 this function does not do
  anything.
- domain_vpl011_init() takes a pointer to a structure which contains all the
  required information such as console_domid, gfn instead of passing parameters
  separately.
- Dropped a DOMCTL API defined for de-initializing vpl011 as that should be
  taken care when the domain is destroyed (and not dependent on userspace
  libraries/applications).

Changes since v2:
- Replaced the DOMCTL APIs defined for get/set of event channel and GFN with
  a set of DOMCTL APIs for initializing and de-initializing vpl011 emulation.

 tools/libxc/include/xenctrl.h | 18 ++
 tools/libxc/xc_domain.c   | 24 
 tools/libxl/libxl_arch.h  |  6 ++
 tools/libxl/libxl_arm.c   | 20 
 tools/libxl/libxl_dom.c   |  4 
 tools/libxl/libxl_x86.c   |  8 
 xen/arch/arm/domain.c |  5 +
 xen/arch/arm/domctl.c | 37 +
 xen/include/public/domctl.h   | 21 +


You need to CC "THE REST" maintainers for this header.


 9 files changed, 143 insertions(+)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index c51bb3b..423c6f3 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -886,6 +886,24 @@ int xc_vcpu_getcontext(xc_interface *xch,
vcpu_guest_context_any_t *ctxt);

 /**
+ * This function initializes the vpl011 emulation and returns
+ * the event to be used by the backend for communicating with
+ * the emulation code.
+ *
+ * @parm xch a handle to an open hypervisor interface
+ * @parm domid the domain to get information from
+ * @parm console_domid the domid of the backend console
+ * @parm gfn the guest pfn to be used as the ring buffer
+ * @parm evtchn the event channel to be used for events
+ * @return 0 on success, negative error on failure
+ */
+int xc_dom_vpl011_init(xc_interface *xch,
+   domid_t domid,
+   uint32_t console_domid,
+   xen_pfn_t gfn,
+   evtchn_port_t *evtchn);
+
+/**
  * This function returns information about the XSAVE state of a particular
  * vcpu of a domain. If extstate->size and extstate->xfeature_mask are 0,
  * the call is considered a query to retrieve them and the buffer is not
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index 3bab4e8..fab3c5e 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -343,6 +343,30 @@ int xc_domain_get_guest_width(xc_interface *xch, uint32_t 
domid,
 return 0;
 }

+int xc_dom_vpl011_init(xc_interface *xch,


Do we really want to call this function xc_dom_vpl011_init? Would not it 
be future proof to call it xc_dom_vuart_init and add a type parameter?



+   domid_t domid,
+   uint32_t console_domid,
+   xen_pfn_t gfn,
+   evtchn_port_t *evtchn)
+{
+DECLARE_DOMCTL;
+int rc = 0;
+
+domctl.cmd = XEN_DOMCTL_vuart_op;
+domctl.domain = (domid_t)domid;
+domctl.u.vuart_op.cmd = XEN_DOMCTL_VUART_OP_INIT;
+domctl.u.vuart_op.type = XEN_DOMCTL_VUART_TYPE_VPL011;
+domctl.u.vuart_op.console_domid = console_domid;
+domctl.u.vuart_op.gfn = gfn;
+
+if ( (rc = do_domctl(xch, &domctl)) < 0 )
+return rc;
+
+*evtchn = domctl.u.vuart_op.evtchn;
+
+return rc;
+}
+
 int xc_domain_getinfo(xc_interface *xch,
   uint32_t first_domid,
   unsigned int max_doms,
diff --git a/tools/libxl/libxl_arch.h b/tools/libxl/libxl_arch.h
index 5e1fc60..118b92c 100644
--- a/tools/libxl/libxl_arch.h
+++ b/tools/libxl/libxl_arch.h
@@ -44,6 +44,12 @@ int libxl__arch_domain_finalise_hw_description(libxl__gc *gc,
   l

Re: [Xen-devel] [OSSTEST PATCH v12 18/21] TestSupport: Implement target_cmd_subunit a subunit stream parser into substeps

Anthony PERARD writes ("Re: [OSSTEST PATCH v12 18/21] TestSupport: Implement 
target_cmd_subunit a subunit stream parser into substeps"):
> On Thu, Jul 13, 2017 at 02:28:11PM +0100, Ian Jackson wrote:
> > I think this is not a critical problem, but fixing it would be nice at
> > some point.
> 
> The subunit stream contains the timestamps, so it just a matter of
> having substep_* taking it as an argument.

Ah.  Well, that can wait.

> > > +sub subunit_sanitize ($) {
> > > +my ($testname) = @_;
> > > +$testname =~ s/ /_/g;
> > > +return $testname;
> > > +}
> > 
> > This function should have a more specific name.  Also it needs to be a
> > whitelist.
> 
> What about subunit_sanitize_testname?

SGTM.

> What kind of whitelist? What should it includes?

I mean: currently, you replace spaces with _s.  But you ought to have
a specific list of characters that you allow without replacing.

It doesn't help that osstest doesn't have an official character set
for testids.  Existing testids (other than various junk) contain
all of
[^;_.()/~0-9a-zA-Z-]
(in Perl regexp charset syntax).

I suggest permitting all of those except ; which seems to have been a
mistake and has now been eliminated.  You may want to permit [ ] too.

> > Does the subunit protocol insist that
> > the spaces are single spaces ?  If not you need to use \s+.  You may
> > want to use the extended regexp syntax.
> 
> Looking at a description of the protocol and at the subunit code, does
> are single spaces.

Fair enough.

> What do you mean by "extended" ? Maybe operator like /.+?/, or maybe
> /(?pattern)/ ?

I mean //x.  See "/x" in perlre(1).  This is a matter of taste.

> multipart just describes how the following lines are formated, it would
> have the 'content-type:' and the size of the output. non-multipart is
> just followed by text, and ends with '\n]\n' (both format do).
> 
> I don't think the code needs to care about it, just that it may or
> may not be there.

Hrm.

> > Does the subunit protocol not have any escaping ?  (Ie, what happens
> > if a thing run as part of a subunit test actually generates a line of
> > log output "]" ?)  If it does havve some escaping you need to
> > de-escape it.
> 
> Without "multipart", there does not seems to be any escaping. With
> multipart, the size of the output is in the protocol, I could extend the
> parser take it into account. It's just more work.

I think you must be able to consume the "multipart" and use the size,
then.  Otherwise if a test case printed output containing "\n]\n", in
multipart format, you would mishandle it and get desynchronised.

> FYI, part of the protocol about the output (with the beginning of
> DETAILS been "\[( multipart)?" in the regex):
> 
> DETAILS ::= BRACKETED | MULTIPART
> BRACKETED ::= '[' CR UTF8-lines ']' CR
> MULTIPART ::= '[ multipart' CR PART* ']' CR
> PART ::= PART_TYPE CR NAME CR PART_BYTES CR
> PART_TYPE ::= Content-Type: type/sub-type(;parameter=value,parameter=value)
> PART_BYTES ::= (DIGITS CR LF BYTE{DIGITS})* '0' CR LF

Sounds like you have to parse the multipart counted parts, I'm afraid.

> > What are subunit v1 consumers supposed to do with 1. unknown keywords
> > 2. syntax errors ?
> > I doubt that the answer to (2) is to ignore them as you do here...
> 
> "unexpected lines [...] should be forwarded unaltered". That's is in the
> readme of python-subunit project.

"forwarded" where I wonder ?  I guess printing them to logm is fine.
But you shouldn't ignore them, I think.

> As for keywords that can exist, there is "tags:", but in the case of
> tempest, it describe which worker did a test, when there is several
> concurrent worker. There is also "progress:" which is not very usefull
> for osstest. There is maybe more keywords which are test result which I
> should probably find out what there are, but I've got at least the one
> used by Tempest.

Fair enough.

Thanks,
Ian.

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

Re: [Xen-devel] [OSSTEST PATCH v12 18/21] TestSupport: Implement target_cmd_subunit a subunit stream parser into substeps

Anthony PERARD writes ("Re: [OSSTEST PATCH v12 18/21] TestSupport: Implement 
target_cmd_subunit a subunit stream parser into substeps"):
> On Thu, Jul 13, 2017 at 03:43:55PM +0100, Anthony PERARD wrote:
> > Will do. And yes, this will duplicate most of the output. But it can
> > help debug osstest, for everything that the parser ignore.
> 
> I can't figure out what should target_cmd_stashed prototype be. Should
> it be like target_cmd_output (returning the output of the cmd) ? Or
> maybe like target_cmd but return a filename (which contain the output of
> the cmd) ?

Either of these will do I think.  Either return the filename and have
the caller use get_filecontents, or simply return the contents.

> I thought also about returning an file descriptor but it may
> not be a good idee to leave the caller with an open fd.

That's probably annoying.

> Also, how to call the stashed file ? So far, I would go with "$job". Or
> maybe adding an argument to target_cmd_stashed so the caller can choose
> a filename.

target_cmd_stashed should use open_unique_stashfile and should
therefore pass $leafref from its caller.

Ian.

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

Re: [Xen-devel] A document for Xen release management

On Mon, Jul 17, 2017 at 06:58:27PM +0200, Juergen Gross wrote:
> On 17/07/17 17:09, Wei Liu wrote:
> > It is agreed during the summit we should write down such document. Here
> > is my attempt of doing so.
> > 
> > We should probably commit something like this into xen.git so that it
> > gets updated regularly.
> > 
> > Comments are welcome.
> > 
> > -
> > 
> > % Xen Release Management
> > % Wei Liu <>
> > % Revision 1
> > 
> > # Motivation
> > 
> > Over the years we have had different people from different company signning
> 
> signing
> 

Fixed.

And I also realised I shouldn't have written "company" because I don't
want to imply one has to be employed by a company to become RM.

> > up as the Release Manager of Xen. It would be rather wasteful if every new
> > Release Manager has to go over everything and tripped over by the same
> > mistakes again and again.
> > 
> > This file intends to document the process of managing a Xen release. It is
> > mainly written for Release Manager, but other roles (contributors,
> > maintainers and committers) are also encouraged to read this document, so
> > that they can have an idea what to expect from the Release Manager.
> > 
> > # Xen release cycle
> > 
> > The Xen hypervisor project now releases twice a year, at the beginning of
> > June and the beginning of December. The actual release date depends on a lot
> > of factors. 
> > 
> > We can roughly divide one release into two periods. The development period
> > and the freeze period. The former is 4 months long and the latter is about 2
> > months long.
> > 
> > During development period, contributors submit patches to be reviewed and
> > committed into xen.git.
> > 
> > During freeze period, the tree is closed for new features. Only bug fixes 
> > are
> > accepted. This period can be shorter or longer than 2 months. If it ends up
> > longer than 2 months, it eats into the next development period.
> > 
> > # The different roles in a Xen release
> > 
> > ## Release Manager
> > 
> > A trusted developer in the community that owns the release process. The 
> > major
> > goal of the Release Manager is to make sure a Xen release has high quality
> > and doens't slip too much.
> > 
> > The Release Manager will not see much workload during development period, 
> > but
> > expects to see increasing workload during the freeze period until the final
> > release. He or she is expected to keep track of issues, arrange RCs,
> > negotiate with relevant stakeholders, balance the need from various parties
> > and make difficult decisions when necessary.
> > 
> > The Release Manager essentially owns xen-unstable branch during the freeze
> > period. The committers will act on the wishes of the Release Manager during
> > that time.
> > 
> > ## Maintainers
> > 
> > A group of trusted developers who are responsible for certain components in
> > xen.git. They are expected to respond to patches / questions with regard to
> > their components in a timely manner, especially during the freeze period.
> > 
> > ## Committers
> > 
> > A group of trusted maintainers who can commit to xen.git. During the
> > development window they normally push things as they see fit. During the
> > freeze period they transfer xen-unstable branch ownership and act on the
> > wishes of the Release Manager. That normally means they need to have an
> > Release Ack in order to push a patch.
> > 
> > ## Contributors
> > 
> > Contributors are also expected to respond quickly to any issues regarding 
> > the
> > code they submitted during development period. Failing that, the Release
> > Manager might decide to revert the changes, declare feature unsupported or
> > take any action he / she deems appropriate.
> > 
> > ## The Security Team
> > 
> > The Security Team operates independently. The visibility might be rather
> > limited due to the sensitive nature of security work. The best action the
> > Release Manager can take is to set aside some time for potential security
> > issues to be fixed.
> > 
> > ## The Release Technician
> > 
> > The Release Technician is the person who tags various trees, prepares 
> > tarball
> > etc. He or she acts on the wishes of the Release Manager. Please make sure
> > the communication is as clear as it can be.
> > 
> > ## The Community Manager
> > 
> > The Community Manager owns xenproject.org infrastructure. He or she is
> > responsible for updating various web archives, updating wiki pages and
> > coordinating with the PR Personnel.
> > 
> > ## The PR Personnel
> > 
> > They are responsible for corrdinating with external reporters to publish Xen
> 
> coordinating
> 

Fixed.

> > release announcement. The Release Manager should be absolutely sure the
> > release is going out on a particular date before giving them the signal to
> > proceed, because there is a point of no return once they schedule a date 
> > with
> > external reporters.
> > 
> > # What happens during a release
> > 
> > ## Development period
> > 
> > Send out mont

[Xen-devel] [PATCH 0/2] irq, xen: fix event channel masking on suspend/resume

Commit bf22ff45bed664aefb5c4e43029057a199b7070c ("genirq: Avoid
unnecessary low level irq function calls") broke Xen suspend/resume
handling as Xen fiddled with masking/unmasking of event channels (or
irqs) without letting the irq subsystem know about it.

Fix this by setting the correct states in irq and remove the masking
from Xen.

Juergen Gross (2):
  irq: adjust state of irq in resume_irq() when IRQF_FORCE_RESUME set
  xen: dont fiddle with event channel masking in suspend/resume

 drivers/xen/events/events_base.c | 13 +++--
 kernel/irq/chip.c| 10 --
 kernel/irq/internals.h   | 10 ++
 kernel/irq/pm.c  |  2 ++
 4 files changed, 15 insertions(+), 20 deletions(-)

-- 
2.12.3


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

[Xen-devel] [PATCH 1/2] irq: adjust state of irq in resume_irq() when IRQF_FORCE_RESUME set

An irq pretending it got disabled should have its state set
accordingly. Otherwise a potential unmask later won't succeed.

Signed-off-by: Juergen Gross 
---
 kernel/irq/chip.c  | 10 --
 kernel/irq/internals.h | 10 ++
 kernel/irq/pm.c|  2 ++
 3 files changed, 12 insertions(+), 10 deletions(-)

diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index d171bc57e1e0..a3cc37c0c85e 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -170,21 +170,11 @@ static void irq_state_clr_disabled(struct irq_desc *desc)
irqd_clear(&desc->irq_data, IRQD_IRQ_DISABLED);
 }
 
-static void irq_state_set_disabled(struct irq_desc *desc)
-{
-   irqd_set(&desc->irq_data, IRQD_IRQ_DISABLED);
-}
-
 static void irq_state_clr_masked(struct irq_desc *desc)
 {
irqd_clear(&desc->irq_data, IRQD_IRQ_MASKED);
 }
 
-static void irq_state_set_masked(struct irq_desc *desc)
-{
-   irqd_set(&desc->irq_data, IRQD_IRQ_MASKED);
-}
-
 static void irq_state_clr_started(struct irq_desc *desc)
 {
irqd_clear(&desc->irq_data, IRQD_IRQ_STARTED);
diff --git a/kernel/irq/internals.h b/kernel/irq/internals.h
index dbfba9933ed2..a2c48058354c 100644
--- a/kernel/irq/internals.h
+++ b/kernel/irq/internals.h
@@ -227,6 +227,16 @@ static inline bool irqd_has_set(struct irq_data *d, 
unsigned int mask)
return __irqd_to_state(d) & mask;
 }
 
+static inline void irq_state_set_disabled(struct irq_desc *desc)
+{
+   irqd_set(&desc->irq_data, IRQD_IRQ_DISABLED);
+}
+
+static inline void irq_state_set_masked(struct irq_desc *desc)
+{
+   irqd_set(&desc->irq_data, IRQD_IRQ_MASKED);
+}
+
 #undef __irqd_to_state
 
 static inline void kstat_incr_irqs_this_cpu(struct irq_desc *desc)
diff --git a/kernel/irq/pm.c b/kernel/irq/pm.c
index cea1de0161f1..6bd9b58429cc 100644
--- a/kernel/irq/pm.c
+++ b/kernel/irq/pm.c
@@ -149,6 +149,8 @@ static void resume_irq(struct irq_desc *desc)
 
/* Pretend that it got disabled ! */
desc->depth++;
+   irq_state_set_disabled(desc);
+   irq_state_set_masked(desc);
 resume:
desc->istate &= ~IRQS_SUSPENDED;
__enable_irq(desc);
-- 
2.12.3


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

[Xen-devel] [PATCH 2/2] xen: dont fiddle with event channel masking in suspend/resume

Instead of fiddling with masking the event channels during suspend
and resume handling let do the irq subsystem do its job. It will do
the mask and unmask operations as needed.

Signed-off-by: Juergen Gross 
---
 drivers/xen/events/events_base.c | 13 +++--
 1 file changed, 3 insertions(+), 10 deletions(-)

diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c
index b241bfa529ce..bae1f5d36c26 100644
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -343,14 +343,6 @@ static void bind_evtchn_to_cpu(unsigned int chn, unsigned 
int cpu)
info->cpu = cpu;
 }
 
-static void xen_evtchn_mask_all(void)
-{
-   unsigned int evtchn;
-
-   for (evtchn = 0; evtchn < xen_evtchn_nr_channels(); evtchn++)
-   mask_evtchn(evtchn);
-}
-
 /**
  * notify_remote_via_irq - send event to remote end of event channel via irq
  * @irq: irq of event channel to send event to
@@ -1573,7 +1565,6 @@ void xen_irq_resume(void)
struct irq_info *info;
 
/* New event-channel space is not 'live' yet. */
-   xen_evtchn_mask_all();
xen_evtchn_resume();
 
/* No IRQ <-> event-channel mappings. */
@@ -1681,6 +1672,7 @@ module_param(fifo_events, bool, 0);
 void __init xen_init_IRQ(void)
 {
int ret = -EINVAL;
+   unsigned int evtchn;
 
if (fifo_events)
ret = xen_evtchn_fifo_init();
@@ -1692,7 +1684,8 @@ void __init xen_init_IRQ(void)
BUG_ON(!evtchn_to_irq);
 
/* No event channels are 'live' right now. */
-   xen_evtchn_mask_all();
+   for (evtchn = 0; evtchn < xen_evtchn_nr_channels(); evtchn++)
+   mask_evtchn(evtchn);
 
pirq_needs_eoi = pirq_needs_eoi_flag;
 
-- 
2.12.3


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

Re: [Xen-devel] Regression PCI passthrough from 4.5.5 to 4.6.0-rc1

2017-07-17 Thread Andreas Kinzler


Hello Jan, Pasi, all


Jan, I still have access to the hardware so perhaps we can finally solve
this problem.

Feel free to go ahead; I'll be on vacation for the next three weeks.


Perhaps we can shortcut debugging a bit because I looked through the  
patches of XenServer 7.2 and found the attached patch. Now I tried it and  
it seems to solve all the problems. Does that patch look good to you, too?


Regards Andreas


xen-dont-assume-msix-is-masked.patch
Description: Binary data
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH] scripts/get_maintainers.pl: Don't blindly drop "THE REST" maintainers

"THE REST" maintainers should always be CCed for any modification that
don't fall under the responsability of a specific component maintainer.

However, the script get_maintainers.pl will remove "THE REST"
maintainers as soon as one maintainer of a specific component will be
present.

Fix the script once for all.

Signed-off-by: Julien Grall 

---

I am getting annoyed at requesting contributors to CC "THE REST" because
the script didn't properly return the list of maintainers. This should
now be fixed.
---
 scripts/get_maintainer.pl | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
index 2804a5b5df..d3076adfd8 100755
--- a/scripts/get_maintainer.pl
+++ b/scripts/get_maintainer.pl
@@ -571,11 +571,15 @@ sub get_maintainers {
 # Find responsible parties
 
 my %exact_pattern_match_hash = ();
+# By default "THE REST" will be suppressed.
+my $do_not_suppress_the_rest = 0;
 
 foreach my $file (@files) {
 
my %hash;
my $tvi = find_first_section();
+   # Unless stated otherwise, a file is maintained by "THE REST"
+   my $file_maintained_by_the_rest = 1;
while ($tvi < @typevalue) {
my $start = find_starting_index($tvi);
my $end = find_ending_index($tvi);
@@ -633,6 +637,14 @@ sub get_maintainers {
 
foreach my $line (sort {$hash{$b} <=> $hash{$a}} keys %hash) {
add_categories($line);
+   my $role = get_maintainer_role($line);
+
+   # Check the role, if it is not "THE REST" then the file is not
+   # only maintained by "THE REST".
+   if ( get_maintainer_role($line) ne "supporter:THE REST" ) {
+   $file_maintained_by_the_rest = 0;
+   }
+
if ($sections) {
my $i;
my $start = find_starting_index($line);
@@ -657,6 +669,9 @@ sub get_maintainers {
print("\n");
}
}
+   # If the file is only maintained by "THE REST", then CC all of them on
+   # the patch.
+   $do_not_suppress_the_rest = 1 if $file_maintained_by_the_rest;
 }
 
 if ($keywords) {
@@ -666,7 +681,8 @@ sub get_maintainers {
}
 }
 
-if ($email_drop_the_rest_supporter_if_supporter_found && $#email_to > 0) {
+if ($email_drop_the_rest_supporter_if_supporter_found &&
+   !$do_not_suppress_the_rest && $#email_to > 0) {
 my @email_new;
 my $do_replace = 0;
 foreach my $email (@email_to) {
-- 
2.11.0


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

Re: [Xen-devel] [PATCH RFC] xen/evtchn: Implement EVTCHNOP_send_imm as a companian to EVTCHNOP_send

2017-07-17 Thread Stefano Stabellini

On Fri, 14 Jul 2017, Jan Beulich wrote:
> >>> On 13.07.17 at 09:50,  wrote:
> > --- a/xen/common/event_channel.c
> > +++ b/xen/common/event_channel.c
> > @@ -1098,6 +1098,10 @@ long do_event_channel_op(int cmd, 
> > XEN_GUEST_HANDLE_PARAM(void) arg)
> >  break;
> >  }
> >  
> > +case EVTCHNOP_send_imm:
> > +rc = evtchn_send(current->domain, (unsigned long)arg.p);
> 
> Two more things: For one this discards the upper half of the 64-bit
> handle. I'd suggest you instead check it to be zero.

+1, keeping in mind that arg will be 32-bit on ARM32 platforms and
64-bit on ARM64 platforms.

Moreover, evtchn_send takes an unsigned int as argument, why are you
casting arg.p to (unsigned long)?


> And then x86's do_event_channel_op_compat() should refuse to handle
> "immediate" commands.

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

[Xen-devel] [linux-3.18 test] 111920: tolerable FAIL - PUSHED

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-qemuu-nested-intel 10 debian-hvm-install fail in 111893 pass 
in 111920
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail in 111893 
pass in 111920
 test-amd64-i386-freebsd10-amd64 19 guest-start/freebsd.repeat fail pass in 
111893
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 16 
guest-localmigrate/x10 fail pass in 111893
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail pass in 
111893

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop   fail REGR. vs. 110441
 test-amd64-amd64-xl-rtds 10 debian-install   fail REGR. vs. 110441
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail in 111893 REGR. vs. 
110441

Tests which did not succeed, but are not blocking:
 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-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop   fail blocked in 110441
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop   fail blocked in 110441
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail in 111893 
like 110441
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 110441
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 110441
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 110441
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail 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-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 build-arm64-pvops 6 kernel-build fail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass

version targeted for testing:
 linux4d29e8c0e9319ce9d391c57d3133306c05b6cef5
baseline version:
 linux8366868460f8784e30302f441546a9d72ffe1236

Last test of basis   110441  2017-06-14 13:16:35 Z

[Xen-devel] [xen-unstable test] 111912: tolerable FAIL - PUSHED

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-libvirt-xsm  4 host-install(4) broken in 111836 pass in 111912
 test-armhf-armhf-xl-arndale 5 host-ping-check-native fail in 111836 pass in 
111912
 test-armhf-armhf-xl-rtds 12 guest-start  fail in 111836 pass in 111912
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail pass in 
111836

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemut-win7-amd64 18 guest-start/win.repeat fail in 111836 
blocked in 111777
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop   fail in 111836 like 111777
 test-amd64-amd64-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail in 111836 
like 111777
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 111751
 test-amd64-amd64-rumprun-amd64 17 rumprun-demo-xenstorels/xenstorels.repeat 
fail like 111777
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 111777
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 111777
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 111777
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 111777
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 111777
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 111777
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass

version targeted for testing:
 xen

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

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

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

Last test of basis   111837  2017-07-15 12:47:42 Z2 days
Testing same since   111941  2017-07-17 16:48:04 Z0 days1 attempts


People who touched revisions under test:
  Jun Nie 

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



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

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

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

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


Pushing revision :

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

[Xen-devel] [linux-linus bisection] complete test-amd64-amd64-amd64-pvgrub