[Xen-devel] [xen-unstable test] 112809: tolerable trouble: blocked/broken/fail/pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

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
 build-arm64-libvirt   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
 build-arm64   2 hosts-allocate  broken like 112655
 build-arm64-pvops 2 hosts-allocate  broken like 112655
 build-arm64-xsm   2 hosts-allocate  broken like 112655
 build-arm64   3 capture-logsbroken like 112655
 build-arm64-xsm   3 capture-logsbroken like 112655
 build-arm64-pvops 3 capture-logsbroken like 112655
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 112655
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 112655
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 112655
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 112655
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 112655
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 112655
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 112655
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 112655
 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-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-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-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail 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-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-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-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-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 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

version targeted for testing:
 xen  9053a74c08fd6abf43bb45ff932b4386de7e8510
baseline version:
 xen  6e2a4c73564ab907b732059adb317d6ca2d138a2

Last test of basis   112655  2017-08-15 18:46:03 Z7 days
Failing since112674  2017-08-17 00:17:27 Z6 days6 attempts
Testing same since   112809  2017-08-22 04:57:01 Z1 days1 attempts

Re: [Xen-devel] [PATCH V2 9/25] tools/libxl: build DMAR table for a guest with one virtual VTD

[Lan Tianyu]

On 2017年08月22日 21:48, Wei Liu wrote:
>> > Hi, Wei
>> > Thanks for your comments.
>> > 
>> > iirc, HVM only supports one module; DMAR cannot be a new module. Joining to
>> > the existing one is the approach we are taking. 
>> > 
>> > Which kind of conflicts you think should be resolved? If you mean I
>> > forget to free the old buf, I will fix this. If you mean the potential
>> > overlap between the binary passed by admin and DMAR table built here, I
>> > don't have much idea on this. Even without the DMAR table, the binary
>> > may contains MADT or other tables and tool stacks don't intrepret the
>> > binary and check whether there are conflicts, right?
>> > 
> Thinking a bit more about this, when I first said "conflicts" I didn't
> mean to parse the content. I was referring to the code in
> libxl_x86_apci.c which also seems to manipulate acpi_modules.

Code in libxl_x86_acpi.c works for Hvmlite/PVHv2. The code we added is
for hvm guest.

> 
> I would like the code to generate dmar take into consideration
> libxl__dom_load_acpi.
> 

If add dmar table for hvmlite, we should combine dmar table with other
ACPI table and populate into acpi_modules[2]. This is how hvmlite add
other ACPI tables in libxl__dom_load_acpi().


-- 
Best regards
Tianyu Lan

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

Re: [Xen-devel] [Xen-users] UEFI Secure Boot Xen 4.9

[Tamas K Lengyel]

On Tue, May 16, 2017 at 5:04 AM, Daniel Kiper  wrote:
> On Mon, May 15, 2017 at 07:09:54PM +, Bill Jacobs (billjac) wrote:
>> > -Original Message-
>> > From: Daniel Kiper [mailto:daniel.ki...@oracle.com]
>> > Sent: Monday, May 15, 2017 6:13 AM
>> > To: Bill Jacobs (billjac) ; george.dun...@citrix.com
>> > Cc: xen-devel@lists.xen.org; xen-us...@lists.xen.org
>> > Subject: Re: [Xen-users] UEFI Secure Boot Xen 4.9
>> >
>> > Hey,
>> >
>> > CC-ing Xen-devel to spread some knowledge about the issue.
>> >
>> > On Mon, May 15, 2017 at 10:42:23AM +0100, George Dunlap wrote:
>> > > On Wed, May 10, 2017 at 11:36 PM, Bill Jacobs (billjac)
>> > >  wrote:
>> > > > Hi all
>> > > >
>> > > > I gather that with 4.9, UEFI secure boot of Xen should be possible.
>> > > >
>> > > > Is this true?
>> > > >
>> > > > If so, what are the options for utilizing UEFI secure boot? Do I
>> > > > need a MSFT-signed shim or grub? Any special changes required for
>> > > > Xen kernel
>> > > > (signing?) or has that been done?
>> > >
>> > > Bill,
>> > >
>> > > I guess in part it depends on what you mean by "utilizing UEFI secure
>> > > boot".  If you simply want to boot an unsigned Xen on a UEFI system
>> > > with SecureBoot enabled, then grub would probably work.  If you want
>> > > to actually do the full SecureBoot thing -- where you have grub check
>> > > Xen's signature and that of the kernel and initrd, you probably need a
>> > > bit more.
>> > >
>> > > Daniel,
>> > >
>> > > Is there any good documentation on this?  The Xen EFI guide
>> > > (https://wiki.xenproject.org/wiki/Xen_EFI) mentions the shim, but
>> > > doesn't go into detail about how to sign a binary 
>> >
>> > Unfortunately I do not know anything like that. As you said in general 
>> > shim is
>> > supported. Sadly, it works only if you load xen.efi directly from EFI.
>> > __Upstream__ GRUB2 has not have support for shim yet. I am working on it
>> > (shim support via GRUB2 requires also some changes in Xen). I hope that I 
>> > will
>> > have something which works before Xen conf in Budapest.
>> >
>> > If you wish to use shim with xen.efi then you have to sign xen.efi and 
>> > vmlinux
>> > with your key using sbsign or pesign. The process works in the same way 
>> > like in
>> > case vmlinux alone. Of course you have to install your public key into MOK
>> > before enabling secure boot.
>> >
>> > Daniel
>>
>> Yes, there are options in how this is achievable, and the solutions may be 
>> different.
>>
>> We are targeting a secure boot chain from UEFI fw to .ko, using same signing.
>> In our case would skip shim and reduce attack surface, but it appears that 
>> the mechanisms
>> 'out there' for passing pub key (cert) from UEFI db to Linux chainring 
>> require shim to do
>> the work. Is that accurate? Does it have to be the case? I don't see why.
>
> AIUI, if EFI secure boot is enabled then EFI verifies signatures of every
> loaded/executed PE file. Unfortunately, you are not able to use secure boot
> protocol directly to verify yourself PE's loaded from your app. So, this is
> one of reasons why shim was introduced. It exposes protocol which can be
> used by you to do verification.
>
>> For us, ideal case is :
>> UEFI fw -> (signed)GRUB2.efi->Multiboot2->Xen(signed .ko)
>
> AFAICT, it is not possible. We should do following thing:
>
>   UEFI -> shim -> GRUB2 -> Multiboot2 -> Xen/Linux/etc.
>
> UEFI will verify shim secure boot signature then shim will verify GRUB2
> signature then GRUB2 will verify (with shim protocol) Xen signature and
> finally Xen will verify (with shim protocol) Linux kernel signature. Then
> your kernel can verify modules using whatever you want.
>
>> I would be happy to work to help achieve this.
>
> There is a chance that I will have something very raw at the beginning
> of June. If you wish to do tests drop me a line.

Hi Daniel,
is there any news on this? I would be interested in giving this a shot too.

Thanks,
Tamas

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

[Xen-devel] [xen-4.5-testing test] 112800: regressions - FAIL

[osstest service owner]

flight 112800 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112800/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-debianhvm-amd64 16 guest-localmigrate/x10 fail REGR. 
vs. 110906
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
110906
 test-amd64-i386-xl-qemuu-winxpsp3 16 guest-localmigrate/x10 fail REGR. vs. 
110906

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds  7 xen-boot fail REGR. vs. 110906

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop   fail blocked in 110906
 test-amd64-amd64-xl-rtds  7 xen-boot fail  like 110906
 test-xtf-amd64-amd64-2   59 leak-check/check fail  like 110906
 test-xtf-amd64-amd64-3   59 leak-check/check fail  like 110906
 test-xtf-amd64-amd64-4   59 leak-check/check fail  like 110906
 test-xtf-amd64-amd64-5   59 leak-check/check fail  like 110906
 test-xtf-amd64-amd64-1   59 leak-check/check fail  like 110906
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 110906
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 110906
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 110906
 test-xtf-amd64-amd64-2   19 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-2 33 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-2 40 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-2   44 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-4   19 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-5   19 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-4 33 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-5 33 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-4 40 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-4   44 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-5 40 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-5   44 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-1   19 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-1 33 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-amd64-amd64-xl-pvh-intel 15 guest-saverestorefail  never pass
 test-xtf-amd64-amd64-1 40 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-amd64-amd64-xl-pvh-amd  12 guest-start  fail   never pass
 test-xtf-amd64-amd64-1   44 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-2   58 xtf/test-hvm64-xsa-195   fail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-xtf-amd64-amd64-3   58 xtf/test-hvm64-xsa-195   fail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-xtf-amd64-amd64-4   58 xtf/test-hvm64-xsa-195   fail   never pass
 test-xtf-amd64-amd64-5   58 xtf/test-hvm64-xsa-195   fail   never pass
 test-xtf-amd64-amd64-1   58 xtf/test-hvm64-xsa-195   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-amd64-xl-qemuu-ws16-amd64 13 guest-saverestore  fail 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-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 13 guest-saverestore  fail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 guest-start  fail   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-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 

Re: [Xen-devel] Xen 4.10 Development Update

[Yu Zhang]

On 8/22/2017 8:44 PM, Julien Grall wrote:

Hi,

On 22/08/17 11:22, Yu Zhang wrote:



On 8/21/2017 6:15 PM, Julien Grall wrote:

Hi Paul,

On 21/08/17 11:11, Paul Durrant wrote:

-Original Message-
From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of
Julien Grall
Sent: 21 August 2017 11:08
To: xen-de...@lists.xenproject.org
Cc: julien.gr...@arm.com
Subject: [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


I think this is either done or obsolete now. Not sure which.


CCed Yu Zhang to tell which one.



Thanks, Julien. This is done now. :)


I may have messed up with the update. Was it upstreamed for Xen 4.9 or 
Xen 4.10? For the former, I will just totally remove it from the update.


It was merged in Xen 4.9. We can just remove this from the update. :-)

Thanks
Yu



Cheers,




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

Re: [Xen-devel] [PATCH V2 6/25] tools/libacpi: Add DMA remapping reporting (DMAR) ACPI table structures

[Lan Tianyu]

On 2017年08月22日 20:56, Wei Liu wrote:
> On Wed, Aug 09, 2017 at 04:34:07PM -0400, Lan Tianyu wrote:
>> From: Chao Gao 
>>
>> Add dmar table structure according Chapter 8 "BIOS Considerations" of
>> VTd spec Rev. 2.4.
>>
>> VTd 
>> spec:http://www.intel.com/content/dam/www/public/us/en/documents/product-specifications/vt-directed-io-spec.pdf
>>
>> Signed-off-by: Chao Gao 
>> Signed-off-by: Lan Tianyu 
> 
> I check the spec and the content, they match.
> 

Thanks.

-- 
Best regards
Tianyu Lan

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

Re: [Xen-devel] [PATCH V2 8/25] tools/libxl: Add a user configurable parameter to control vIOMMU attributes

[Lan Tianyu]

On 2017年08月22日 21:19, Wei Liu wrote:
>> +=over 4
>> > +
>> > +=item 

Re: [Xen-devel] [PATCH 6/6] libxl: support unmapping static shared memory areas during domain destruction

[Zhongze Liu]

Hi Stefano,

2017-08-23 5:31 GMT+08:00 Stefano Stabellini :
> On Wed, 23 Aug 2017, Zhongze Liu wrote:
>> Add libxl__sshm_del to Unmap static shared memory areas mapped by
>> libxl__sshm_add during domain creation. The unmapping process is:
>>
>> * For a master: check if it still has living slaves: 1) if yes, mark its
>>   status as "zombie", and don't destroy the information under
>>   /local/static_shm; 2) if no, simply cleanup related xs entries
>> * For a slave: unmap the shared pages, and cleanup related xs entries. If
>>   this is the only slave, and it's master is in zombie state, also cleanup
>>   the master entries.
>>
>> This is for the proposal "Allow setting up shared memory areas between VMs
>> from xl config file" (see [1]).
>>
>> [1] 
>> https://lists.xenproject.org/archives/html/xen-devel/2017-07/msg03047.html
>>
>> Signed-off-by: Zhongze Liu 
>>
>> Cc: Ian Jackson 
>> Cc: Wei Liu 
>> Cc: Stefano Stabellini 
>> Cc: Julien Grall 
>> Cc: xen-devel@lists.xen.org
>> ---
>>  tools/libxl/libxl_domain.c   |   5 ++
>>  tools/libxl/libxl_internal.h |   2 +
>>  tools/libxl/libxl_sshm.c | 125 
>> +++
>>  3 files changed, 132 insertions(+)
>>
>> diff --git a/tools/libxl/libxl_domain.c b/tools/libxl/libxl_domain.c
>> index 08eccd082b..73ac856fb4 100644
>> --- a/tools/libxl/libxl_domain.c
>> +++ b/tools/libxl/libxl_domain.c
>> @@ -1028,6 +1028,11 @@ void libxl__destroy_domid(libxl__egc *egc, 
>> libxl__destroy_domid_state *dis)
>>  goto out;
>>  }
>>
>> +rc = libxl__sshm_del(gc, domid);
>> +if (rc) {
>> +LOGD(ERROR, domid, "Deleting static shm failed.");
>> +}
>> +
>>  if (libxl__device_pci_destroy_all(gc, domid) < 0)
>>  LOGD(ERROR, domid, "Pci shutdown failed");
>>  rc = xc_domain_pause(ctx->xch, domid);
>> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
>> index 74bc0acb21..648eaee8c2 100644
>> --- a/tools/libxl/libxl_internal.h
>> +++ b/tools/libxl/libxl_internal.h
>> @@ -4361,6 +4361,8 @@ static inline bool libxl__acpi_defbool_val(const 
>> libxl_domain_build_info *b_info
>>  _hidden int libxl__sshm_add(libxl__gc *gc, uint32_t domid,
>>  libxl_static_shm *sshm, int len);
>>
>> +_hidden int libxl__sshm_del(libxl__gc *gc, uint32_t domid);
>> +
>>  _hidden int libxl__sshm_check_overlap(libxl__gc *gc, uint32_t domid,
>>libxl_static_shm *sshms, int len);
>>  _hidden int libxl__sshm_setdefault(libxl__gc *gc, uint32_t domid,
>> diff --git a/tools/libxl/libxl_sshm.c b/tools/libxl/libxl_sshm.c
>> index e16c24ccb9..417a4cd0a4 100644
>> --- a/tools/libxl/libxl_sshm.c
>> +++ b/tools/libxl/libxl_sshm.c
>> @@ -79,6 +79,131 @@ int libxl__sshm_check_overlap(libxl__gc *gc, uint32_t 
>> domid,
>>  return 0;
>>  }
>>
>> +/* Delete sshm master infomation from xenstore. If there are still living
>> + * slaves, mark the master as in zombie state, but do not delete it,
>> + * and it will be totally deleted later after all slaves are gone */
>> +static void libxl__sshm_del_master(libxl__gc *gc, xs_transaction_t xt,
>> +   uint32_t domid, const char *id)
>> +{
>> +char *sshm_path;
>> +
>> +sshm_path = libxl__xs_get_sshmpath(gc, id);
>> +
>> +/* we know that domid can't be both a master and a slave for one id
>> + * (enforced in the *_add_master() and *_add_slave() code),
>> + * so the number of slaves won't change during iteration. Simply check
>> + * sshm_path/slaves to tell if there are still living slaves. */
>> +if (libxl__xs_read(gc, xt, GCSPRINTF("%s/slaves", sshm_path))) {
>
> Is it possible that "slaves" is present but empty? What does
> libxl__xs_read return in that case?

Because I didn't create the "slaves" entry directly, it's
automatically created when I
write things to slaves/*. So when all the slaves are gone, it will go away. This
is what I observed during a local test, but not very sure if it's the
expected behavior.

Cheer,

Zhongze Liu
>
>
>> +SSHM_ERROR(domid, id,
>> +   "there are living slaves, won't be totally destroyed");
>> +
>> +libxl__xs_write_checked(gc, xt,
>> +GCSPRINTF("%s/status", sshm_path),
>> +"zombie");
>> +} else {
>> +libxl__xs_path_cleanup(gc, xt, sshm_path);
>> +}
>> +
>> +return;
>> +}
>> +
>> +static void libxl__sshm_do_unmap(libxl__gc *gc, uint32_t domid, const char 
>> *id,
>> + uint64_t begin, uint64_t end)
>> +{
>> +begin >>= 12;
>> +end >>= 12;
>> +for (; begin < end; ++begin) {
>> +if (xc_domain_remove_from_physmap(CTX->xch, domid, begin)) {
>> +SSHM_ERROR(domid, id,
>> +   "unable to unmap shared 

Re: [Xen-devel] [PATCH V2 7/25] tools/libacpi: Add new fields in acpi_config for DMAR table

[Lan Tianyu]

On 2017年08月22日 21:12, Wei Liu wrote:
> On Wed, Aug 09, 2017 at 04:34:08PM -0400, Lan Tianyu wrote:
>> From: Chao Gao 
>>
>> The BIOS reports the remapping hardware units in a platform to system 
>> software
>> through the DMA Remapping Reporting (DMAR) ACPI table.
>> New fields are introduces for DMAR table. These new fields are set by
>> toolstack through parsing guest's config file. construct_dmar() is added to
>> build DMAR table according to the new fields.
>>
>> Signed-off-by: Chao Gao 
>> Signed-off-by: Lan Tianyu 
>> ---
>>  tools/libacpi/build.c   | 57 
>> +
>>  tools/libacpi/libacpi.h |  9 
>>  2 files changed, 66 insertions(+)
>>
>> diff --git a/tools/libacpi/build.c b/tools/libacpi/build.c
>> index f9881c9..c7cc784 100644
>> --- a/tools/libacpi/build.c
>> +++ b/tools/libacpi/build.c
>> @@ -28,6 +28,10 @@
>>  
>>  #define ACPI_MAX_SECONDARY_TABLES 16
>>  
>> +#define VTD_HOST_ADDRESS_WIDTH 39
>> +#define I440_PSEUDO_BUS_PLATFORM 0xff
>> +#define I440_PSEUDO_DEVFN_IOAPIC 0x0
> 
> I have some stupid questions. What are these I440 values? Where do they
> come from?
> 

Each IOAPIC device in the system reported via ACPI MADT must be
explicitly enumerated under one specific remapping hardware unit. We
assigned IOAPCI unit to bdf ff:00 and referenced Qemu vIOMMU implementation.


-- 
Best regards
Tianyu Lan

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

Re: [Xen-devel] [PATCH 5/6] libxl: support mapping static shared memory areas during domain creation

[Zhongze Liu]

Hi Stefano,

2017-08-23 5:42 GMT+08:00 Stefano Stabellini :
> On Wed, 23 Aug 2017, Zhongze Liu wrote:
>> Add libxl__sshm_add to map shared pages from one DomU to another, The mapping
>> process involves the follwing steps:
>>
>>   * Set defaults and check for further errors in the static_shm configs:
>> overlapping areas, invalid ranges, duplicated master domain,
>> no master domain etc.
>>   * Write infomation of static shared memory areas into the appropriate
>> xenstore paths.
>>   * use xc_domain_add_to_physmap_batch to do the page sharing.
>>
>> Temporarily mark this as unsupported on x86 because calling p2m_add_foregin 
>> on
>> two domU's is currently not allowd on x86 (see the comments in
>> x86/mm/p2m.c:p2m_add_foregin for more details).
>>
>> This is for the proposal "Allow setting up shared memory areas between VMs
>> from xl config file" (see [1]).
>>
>> [1] 
>> https://lists.xenproject.org/archives/html/xen-devel/2017-07/msg03047.html
>>
>> Signed-off-by: Zhongze Liu 
>>
>> Cc: Andrew Cooper 
>> Cc: George Dunlap 
>> Cc: Ian Jackson 
>> Cc: Jan Beulich 
>> Cc: Konrad Rzeszutek Wilk 
>> Cc: Stefano Stabellini 
>> Cc: Tim Deegan 
>> Cc: Wei Liu 
>> Cc: Julien Grall 
>> Cc: xen-devel@lists.xen.org
>> ---
>>  tools/libxl/Makefile |   2 +-
>>  tools/libxl/libxl_arch.h |   6 +
>>  tools/libxl/libxl_arm.c  |  15 ++
>>  tools/libxl/libxl_create.c   |  27 
>>  tools/libxl/libxl_internal.h |  14 ++
>>  tools/libxl/libxl_sshm.c | 336 
>> +++
>>  tools/libxl/libxl_x86.c  |  18 +++
>>  tools/libxl/libxl_xshelp.c   |   8 ++
>>  8 files changed, 425 insertions(+), 1 deletion(-)
>>  create mode 100644 tools/libxl/libxl_sshm.c
>>
>> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
>> index 3b63fb2cad..fd624b28f3 100644
>> --- a/tools/libxl/Makefile
>> +++ b/tools/libxl/Makefile
>> @@ -138,7 +138,7 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_create.o 
>> libxl_dm.o libxl_pci.o \
>>   libxl_dom_suspend.o libxl_dom_save.o libxl_usb.o \
>>   libxl_vtpm.o libxl_nic.o libxl_disk.o libxl_console.o \
>>   libxl_cpupool.o libxl_mem.o libxl_sched.o libxl_tmem.o 
>> \
>> - libxl_9pfs.o libxl_domain.o \
>> + libxl_9pfs.o libxl_domain.o libxl_sshm.o \
>>  $(LIBXL_OBJS-y)
>>  LIBXL_OBJS += libxl_genid.o
>>  LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
>> diff --git a/tools/libxl/libxl_arch.h b/tools/libxl/libxl_arch.h
>> index 5e1fc6060e..1d681d8863 100644
>> --- a/tools/libxl/libxl_arch.h
>> +++ b/tools/libxl/libxl_arch.h
>> @@ -71,6 +71,12 @@ int libxl__arch_extra_memory(libxl__gc *gc,
>>   const libxl_domain_build_info *info,
>>   uint64_t *out);
>>
>> +_hidden
>> +bool libxl__arch_domain_support_sshm(const libxl_domain_build_info *b_info);
>> +
>> +_hidden
>> +int libxl__arch_domain_sshm_cachepolicy_setdefault(libxl_static_shm *sshm);
>> +
>>  #if defined(__i386__) || defined(__x86_64__)
>>
>>  #define LAPIC_BASE_ADDRESS  0xfee0
>> diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
>> index d842d888eb..0975109c0c 100644
>> --- a/tools/libxl/libxl_arm.c
>> +++ b/tools/libxl/libxl_arm.c
>> @@ -1065,6 +1065,21 @@ void libxl__arch_domain_build_info_acpi_setdefault(
>>  libxl_defbool_setdefault(_info->acpi, false);
>>  }
>>
>> +bool libxl__arch_domain_support_sshm(const libxl_domain_build_info *b_info)
>> +{
>> +return true;
>> +}
>> +
>> +int libxl__arch_domain_sshm_cachepolicy_setdefault(libxl_static_shm *sshm)
>> +{
>> +if (sshm->cache_policy == LIBXL_SSHM_CACHEPOLICY_UNKNOWN)
>> +sshm->cache_policy = LIBXL_SSHM_CACHEPOLICY_ARM_NORMAL;
>> +if (sshm->cache_policy >= LIBXL_SSHM_CACHEPOLICY_X86_NORMAL)
>> +return ERROR_INVAL;
>> +
>> +return 0;
>> +}
>> +
>>  /*
>>   * Local variables:
>>   * mode: C
>> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
>> index 1158303e1a..8e5ec486d2 100644
>> --- a/tools/libxl/libxl_create.c
>> +++ b/tools/libxl/libxl_create.c
>> @@ -501,6 +501,14 @@ int libxl__domain_build(libxl__gc *gc,
>>  ret = ERROR_INVAL;
>>  goto out;
>>  }
>> +
>> +/* the p2m has been setup, we could map the static shared memory now. */
>> +ret = libxl__sshm_add(gc, domid, d_config->sshms, d_config->num_sshms);
>> +if (ret != 0) {
>> +LOG(ERROR, "failed to map static shared memory");
>> +goto out;
>> +}
>> +
>>  ret = libxl__build_post(gc, domid, info, state, vments, localents);
>>  out:
>>  return ret;
>> @@ -918,6 +926,25 @@ static void 

Re: [Xen-devel] [PATCH 4/6] xsm: flask: change the interface and default policy for xsm_map_gmfn_foregin

[Zhongze Liu]

Hi Stefano,

2017-08-23 3:58 GMT+08:00 Stefano Stabellini :
> On Wed, 23 Aug 2017, Zhongze Liu wrote:
>> The original xsm_map_gmfn_foregin policy checks if source domain has the 
>> proper
>> privileges over the target domain. Under this policy, it's not allowed if a 
>> Dom0
>> wants to map pages from one DomU to another, this restricts some useful yet 
>> not
>> dangerous usages of the API, such as sharing pages among DomU's by calling
>> XENMEM_add_to_physmap from Dom0.
>>
>> Change the policy to: IIF current domain has the proper privilege on the
> ^ IFF
>
>
>> target domain and source domain, grant the access.
>>
>> References to this xsm check have also been updated to pass the current
>> domain as a new parameter.
>>
>> This is for the proposal "Allow setting up shared memory areas between VMs
>> from xl config file" (see [1]).
>>
>> [1] 
>> https://lists.xenproject.org/archives/html/xen-devel/2017-07/msg03047.html
>>
>> Signed-off-by: Zhongze Liu 
>>
>> Cc: Stefano Stabellini 
>> Cc: Julien Grall 
>> Cc: George Dunlap 
>> Cc: Jan Beulich 
>> Cc: Andrew Cooper 
>> Cc: Daniel De Graaf 
>> Cc: xen-devel@lists.xen.org
>> ---
>>  xen/arch/arm/mm.c   | 2 +-
>>  xen/arch/x86/mm/p2m.c   | 2 +-
>>  xen/include/xsm/dummy.h | 6 --
>>  xen/include/xsm/xsm.h   | 7 ---
>>  xen/xsm/flask/hooks.c   | 6 --
>>  5 files changed, 14 insertions(+), 9 deletions(-)
>>
>> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
>> index a810a056d7..9ec78d8c03 100644
>> --- a/xen/arch/arm/mm.c
>> +++ b/xen/arch/arm/mm.c
>> @@ -1284,7 +1284,7 @@ int xenmem_add_to_physmap_one(
>>  return -EINVAL;
>>  }
>>
>> -rc = xsm_map_gmfn_foreign(XSM_TARGET, d, od);
>> +rc = xsm_map_gmfn_foreign(XSM_TARGET, current->domain, d, od);
>>  if ( rc )
>>  {
>>  rcu_unlock_domain(od);
>> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
>> index e8a57d118c..a547fd00c0 100644
>> --- a/xen/arch/x86/mm/p2m.c
>> +++ b/xen/arch/x86/mm/p2m.c
>> @@ -2545,7 +2545,7 @@ int p2m_add_foreign(struct domain *tdom, unsigned long 
>> fgfn,
>>  if ( tdom == fdom )
>>  goto out;
>>
>> -rc = xsm_map_gmfn_foreign(XSM_TARGET, tdom, fdom);
>> +rc = xsm_map_gmfn_foreign(XSM_TARGET, current->domain, tdom, fdom);
>>  if ( rc )
>>  goto out;
>>
>> diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
>> index 62fcea6f04..28dbc6f2a2 100644
>> --- a/xen/include/xsm/dummy.h
>> +++ b/xen/include/xsm/dummy.h
>> @@ -525,10 +525,12 @@ static XSM_INLINE int 
>> xsm_remove_from_physmap(XSM_DEFAULT_ARG struct domain *d1,
>>  return xsm_default_action(action, d1, d2);
>>  }
>>
>> -static XSM_INLINE int xsm_map_gmfn_foreign(XSM_DEFAULT_ARG struct domain 
>> *d, struct domain *t)
>> +static XSM_INLINE int xsm_map_gmfn_foreign(XSM_DEFAULT_ARG struct domain 
>> *cd,
>> +   struct domain *d, struct domain 
>> *t)
>>  {
>>  XSM_ASSERT_ACTION(XSM_TARGET);
>> -return xsm_default_action(action, d, t);
>> +return xsm_default_action(action, cd, d) ||
>> +xsm_default_action(action, cd, t);
>
> We need to preserve the returned errors:
>
>   rc = xsm_default_action(action, cd, d);
>   if (rc) return rc;
>   return xsm_default_action(action, cd, t);

OK, will correct this.

>
>
>
>>  }
>>
>>  static XSM_INLINE int xsm_hvm_param(XSM_DEFAULT_ARG struct domain *d, 
>> unsigned long op)
>> diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
>> index 60c0fd6a62..a20654a803 100644
>> --- a/xen/include/xsm/xsm.h
>> +++ b/xen/include/xsm/xsm.h
>> @@ -85,7 +85,7 @@ struct xsm_operations {
>>  int (*memory_pin_page) (struct domain *d1, struct domain *d2, struct 
>> page_info *page);
>>  int (*add_to_physmap) (struct domain *d1, struct domain *d2);
>>  int (*remove_from_physmap) (struct domain *d1, struct domain *d2);
>> -int (*map_gmfn_foreign) (struct domain *d, struct domain *t);
>> +int (*map_gmfn_foreign) (struct domain *cd, struct domain *d, struct 
>> domain *t);
>>  int (*claim_pages) (struct domain *d);
>>
>>  int (*console_io) (struct domain *d, int cmd);
>> @@ -372,9 +372,10 @@ static inline int xsm_remove_from_physmap(xsm_default_t 
>> def, struct domain *d1,
>>  return xsm_ops->remove_from_physmap(d1, d2);
>>  }
>>
>> -static inline int xsm_map_gmfn_foreign (xsm_default_t def, struct domain 
>> *d, struct domain *t)
>> +static inline int xsm_map_gmfn_foreign (xsm_default_t def, struct domain 
>> *cd,
>> +struct domain *d, struct domain *t)
>>  {
>> -return xsm_ops->map_gmfn_foreign(d, t);
>> +return xsm_ops->map_gmfn_foreign(cd, d, t);
>>  }
>>
>>  static inline int xsm_claim_pages(xsm_default_t def, struct 

Re: [Xen-devel] [PATCH V2 4/25] Xen/doc: Add Xen virtual IOMMU doc

[Lan Tianyu]

On 2017年08月22日 19:03, Wei Liu wrote:
> On Tue, Aug 22, 2017 at 04:07:32PM +0800, Lan Tianyu wrote:
>> On 2017年08月18日 18:15, Wei Liu wrote:
>>> On Fri, Aug 18, 2017 at 03:17:37PM +0800, Lan Tianyu wrote:
 On 2017年08月17日 19:19, Wei Liu wrote:
> On Wed, Aug 09, 2017 at 04:34:05PM -0400, Lan Tianyu wrote:
>> +Now just suppport single vIOMMU for one VM and introduced domctls are 
>> compatible
>> +with multi-vIOMMU support.
>
> Is this still true? 

 Yes, the patchset just supports single vIOMMU for one VM.

>>>
>>> The first part of the sentence is true, but the latter is probably not.
>>> It seems to me domctl is able to cope with multiple viommu. Please
>>> correct me if I'm wrong.
>>
>> These domctl is able to support multiple vIOMMU but vIOMMU device model
>> in Xen hypervisor only support single vIOMMU for one VM.
>>
> 
> In that case please update the document.
> 

OK. Will update.

-- 
Best regards
Tianyu Lan

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

Re: [Xen-devel] [PATCH v7] VT-d: use correct BDF for VF to search VT-d unit

[Chao Gao]

On Tue, Aug 22, 2017 at 06:43:49AM -0600, Jan Beulich wrote:
 On 21.08.17 at 23:52,  wrote:
>> --- a/xen/include/xen/pci.h
>> +++ b/xen/include/xen/pci.h
>> @@ -39,6 +39,10 @@
>>  #define PCI_SBDF3(s,b,df) s) & 0x) << 16) | PCI_BDF2(b, df))
>>  
>>  struct pci_dev_info {
>> +/*
>> + * When 'is_virtfn' is set, 'is_extfn' is re-used to indicate whether
>> + * the PF of this VF is an extended function.
>> + */
>
>I'd be inclined to extend the comment by appending ", as a VF itself
>can never be an extended function." Is that correct? If so, would

Hi, Jan and Roger.

Strictly speaking, the VF can be an extended function. The definition is
within ARI device (in this kind of device, device field is treated as an
extension of function number) and function number is greater than 7. But
this field isn't used as we don't care about whether a VF is or not an
extended function (at least at present).

Eric reviewed this patch and told me we may match
'if ( pdev->info.is_extfn )' in acpi_find_matched_drhd_unit.
So we may introduce a new field like what I do in v6 or check
'pdev->info.is_virtfn' first in acpi_find_matched_drhd_unit (maybe other
places we check pdev->info.is_extfn).

Which one do you prefer?

Thanks
Chao

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

Re: [Xen-devel] [PATCH 2/6] libxl: introduce a new structure to represent static shared memory regions

[Zhongze Liu]

Hi Stefano,

2017-08-23 4:05 GMT+08:00 Stefano Stabellini :
> On Wed, 23 Aug 2017, Zhongze Liu wrote:
>> Add a new structure to the IDL famliy to represent static shared memory 
>> regions,
>   ^ family
>
>
>> as proposed in the proposal "Allow setting up shared memory areas between VMs
>> from xl config file" (see [1]).
>>
>> [1] 
>> https://lists.xenproject.org/archives/html/xen-devel/2017-07/msg03047.html
>>
>> Signed-off-by: Zhongze Liu 
>>
>> Cc: Wei Liu 
>> Cc: Ian Jackson 
>> Cc: Stefano Stabellini 
>> Cc: Julien Grall 
>> Cc: xen-devel@lists.xen.org
>> ---
>>  tools/libxl/libxl.h |  4 
>>  tools/libxl/libxl_types.idl | 36 
>>  2 files changed, 36 insertions(+), 4 deletions(-)
>>
>> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
>> index 229e289750..3ee788642f 100644
>> --- a/tools/libxl/libxl.h
>> +++ b/tools/libxl/libxl.h
>> @@ -2237,6 +2237,10 @@ int libxl_fd_set_nonblock(libxl_ctx *ctx, int fd, int 
>> nonblock);
>>  int libxl_qemu_monitor_command(libxl_ctx *ctx, uint32_t domid,
>> const char *command_line, char **output);
>>
>> +/* Constants for libxl_static_shm */
>> +#define LIBXL_SSHM_RANGE_UNKNOWN UINT64_MAX
>> +#define LIBXL_SSHM_ID_MAXLEN128
>> +
>>  #include 
>>
>>  #endif /* LIBXL_H */
>> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
>> index 6e80d36256..6c9e79c05d 100644
>> --- a/tools/libxl/libxl_types.idl
>> +++ b/tools/libxl/libxl_types.idl
>> @@ -472,7 +472,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
>>  ("blkdev_start",string),
>>
>>  ("vnuma_nodes", Array(libxl_vnode_info, "num_vnuma_nodes")),
>> -
>> +
>
> Although your code style corrections are appropriate, usually we do them
> in separate patches to separate them out from more meaningful changes.
> However, different maintainers have different styles, so Wei might be OK
> with this.
>
> In any case:
>
> Reviewed-by: Stefano Stabellini 

Thanks for reviewing. This is actually a
'clean-trailing-white-space-on-save' feature
of my editor. I always turn it off when modifying the toolstack code,
because there
are trailing white spaces at many unexpected corners and this will screw up the
diff. I don't know why I somehow missed this file. But I think it's
not a big problem
though. I will wait for Wei's comments on this. And it won't be too
hard to restore
the style corrections.

But I think we really should do a big white spaces cleanup in the
toolstack code.

Cheers,

Zhongze Liu
>
>
>>  ("device_model_version", libxl_device_model_version),
>>  ("device_model_stubdomain", libxl_defbool),
>>  # if you set device_model you must set device_model_version too
>> @@ -494,7 +494,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
>>  ("ioports",  Array(libxl_ioport_range, "num_ioports")),
>>  ("irqs", Array(uint32, "num_irqs")),
>>  ("iomem",Array(libxl_iomem_range, "num_iomem")),
>> -("claim_mode",libxl_defbool),
>> +("claim_mode",   libxl_defbool),
>>  ("event_channels",   uint32),
>>  ("kernel",   string),
>>  ("cmdline",  string),
>> @@ -543,10 +543,10 @@ libxl_domain_build_info = Struct("domain_build_info",[
>> ("keymap",   string),
>> ("sdl",  libxl_sdl_info),
>> ("spice",
>> libxl_spice_info),
>> -
>> +
>> ("gfx_passthru", libxl_defbool),
>> ("gfx_passthru_kind", 
>> libxl_gfx_passthru_kind),
>> -
>> +
>> ("serial",   string),
>> ("boot", string),
>> ("usb",  libxl_defbool),
>> @@ -779,6 +779,33 @@ libxl_device_channel = Struct("device_channel", [
>> ])),
>>  ])
>>
>> +libxl_sshm_cachepolicy = Enumeration("sshm_cachepolicy", [
>> +(-1, "UNKNOWN"),
>> +(0,  "ARM_NORMAL"),  # ARM policies should be < 32
>> +(32,  "X86_NORMAL"), # X86 policies should be >= 32
>> +], init_val = "LIBXL_SSHM_CHCHE_POLICY_UNKNOWN")
>> +
>> +libxl_sshm_prot = Enumeration("sshm_prot", [
>> +(-1, "UNKNOWN"),
>> +(3,  "RW"),
>> +], init_val = "LIBXL_SSHM_PROT_UNKNOWN")
>> +
>> +libxl_sshm_role = Enumeration("sshm_role", [
>> +(-1, "UNKNOWN"),
>> +(0,  "MASTER"),
>> +(1,  "SLAVE"),
>> +], init_val = "LIBXL_SSHM_ROLE_UNKNOWN")
>> +
>> +libxl_static_shm = Struct("static_shm", [
>> +("id", string),
>> +("offset", uint64, {'init_val': 'LIBXL_SSHM_RANGE_UNKNOWN'}),
>> +

Re: [Xen-devel] [edk2] [PATCH] Maintainers.txt: update OvmfPkg maintainership

[Konrad Rzeszutek Wilk]

On Thu, Aug 17, 2017 at 01:47:59AM +0200, Laszlo Ersek wrote:
> On 08/17/17 00:37, Jordan Justen wrote:
> > On 2017-08-16 12:23:49, Leif Lindholm wrote:
> 
> [snip]
> 
> >> - the value proposition
> >> for Linaro is that having maintainer parity ArmVirtPkg/OvmfPkg
> >> simplifies the task of maintaining feature parity between the two.
> >> (It is no secret that I would love to see them as a single package,
> >> making it easier to clean up the way EDK2-for-qemu gets packaged by
> >> Linux distributions.)
> > 
> > I would also prefer to have OVMF support ARM and eventually RISC-V as
> > well. I don't think Laszlo feels as confident about this though.
> 
> I have two concerns:
> 
> (1) Reorganizing OvmfPkg for this would take an immense amount of time
> (with possible regressions).
> 
> (2) Sharing more code between modules that aren't inherently
> architecture-independent (and virtualization platform-independent) is risky.
> 
> By "sharing more code", I mean extracting further library classes and
> then unifying originally separate drivers. I also mean extracting common
> files from separate library instances, and then unifying the lib
> instances in a common directory, with multiple INF files, or with
> arch-dependent sections in the one resultant INF file. Another method is
> to control the same set of drivers / library instances differently, via
> dynamic PCDs.
> 
> While all this is great for code de-duplication, the chance of
> regressions skyrockets if the code de-dup is not matched by a similar
> overlap in maintenance (that is, review and testing).
> 
> Personally I use QEMU/KVM (and occasionally QEMU/TCG) on x86 and
> aarch64. I don't use 32-bit ARM (even guests, on aarch64 hosts), or any
> kind of Xen. I've never seen RISC-V hardware (and probably won't --
> nested TCG with QEMU doesn't count).
> 
> The best counter-indication for this kind of increased sharing is the
> *numerous* Xen-related regressions that have slipped through in the
> past, simply because none of the OvmfPkg maintainers use Xen. (And the
> Xen project seems to be unwilling or unable to delegate an official
> reviewer or co-maintainer for the Xen-related code in OvmfPkg, despite
> my repeated requests.) This has happened under ArmVirtPkg too (I recall

Who did you email/speak to? I hadn't seen any emails sent by
you to xen-devel mailing list, but perhaps I missed them?

It should be fairly simple to expand the 0-day OSSTest to build
TianoCore and launch guests with it as a nice regression test.

> ACPI vs. DT related changes -- surprisingly, even *that* selection is
> specific to the virtualization platform.)
> 
> The bottleneck in open source development is not writing code, it is
> reviewing and regression-testing code. (This is painfully obvious in
> Linux kernel and QEMU development, but the same can be experienced on
> edk2-devel as well.) Therefore OvmfPkg's structure should match the
> distribution of OvmfPkg's active stake-holders over architectures and
> virtualization platforms.
> 
> IMO the current code sharing between OvmfPkg and ArmVirtPkg, while
> certainly not 100% polished, is workable -- meaning that it mostly
> corresponds to the stakes that ArmVirtPkg and OvmfPkg maintainers and
> long-term contributors hold in the shared modules.
> 
> In fact, these stakes would be much better reflected if Ard *too* were a
> Maintainer for OvmfPkg.
> 
> Thanks
> Laszlo
> ___
> edk2-devel mailing list
> edk2-de...@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

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

[Xen-devel] [xen-4.7-testing test] 112793: tolerable trouble: blocked/broken/fail/pass - PUSHED

[osstest service owner]

flight 112793 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112793/

Failures :-/ but no regressions.

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

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
 build-arm64-libvirt   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
 build-arm64-xsm   2 hosts-allocate  broken like 112667
 build-arm64-xsm   3 capture-logsbroken like 112667
 build-arm64-pvops 2 hosts-allocate  broken like 112667
 build-arm64   2 hosts-allocate  broken like 112667
 build-arm64-pvops 3 capture-logsbroken like 112667
 build-arm64   3 capture-logsbroken like 112667
 test-xtf-amd64-amd64-1  48 xtf/test-hvm64-lbr-tsx-vmentry fail like 112650
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 112650
 test-xtf-amd64-amd64-5  48 xtf/test-hvm64-lbr-tsx-vmentry fail like 112667
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 112667
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 112667
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 112667
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 112667
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-xl-pvh-amd  12 guest-start  fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 15 guest-saverestorefail  never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   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-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-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-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-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-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-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-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass

version targeted for testing:
 xen  5151257626155d6e331cc9e66d896c84db1611e1
baseline 

[Xen-devel] [libvirt test] 112808: tolerable trouble: blocked/broken/pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 build-arm64-xsm   2 hosts-allocate  broken like 112709
 build-arm64-pvops 2 hosts-allocate  broken like 112709
 build-arm64-xsm   3 capture-logsbroken like 112709
 build-arm64   2 hosts-allocate  broken like 112709
 build-arm64-pvops 3 capture-logsbroken like 112709
 build-arm64   3 capture-logsbroken like 112709
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 112709
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 112709
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 112709
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  0f1993aa15f281b3812806e29df729149a5b64c6
baseline version:
 libvirt  7726d1581f9e433a106f45ed87ec95ece575f817

Last test of basis   112709  2017-08-19 04:20:16 Z3 days
Testing same since   112808  2017-08-22 04:24:14 Z0 days1 attempts


People who touched revisions under test:
  Andrea Bolognani 
  Jim Fehlig 
  Lily Zhu 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  broken  
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-arm64-libvirt  blocked 
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-arm64-pvopsbroken  
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-libvirt-xsm pass
 test-arm64-arm64-libvirt-xsm blocked 
 test-armhf-armhf-libvirt-xsm pass
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-arm64-arm64-libvirt blocked 
 test-armhf-armhf-libvirt pass
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-arm64-arm64-libvirt-qcow2   blocked 
 test-armhf-armhf-libvirt-raw pass
 test-amd64-amd64-libvirt-vhd pass



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

Logs, config files, etc. are available at

[Xen-devel] [xen-4.8-testing test] 112789: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

flight 112789 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112789/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-xtf-amd64-amd64-3 48 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 112664
 test-xtf-amd64-amd64-2 48 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 112664
 test-xtf-amd64-amd64-4 48 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 112664
 test-xtf-amd64-amd64-5 48 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 112664
 test-armhf-armhf-libvirt16 guest-start/debian.repeat fail REGR. vs. 112664

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 12 guest-start  fail REGR. vs. 112664
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stopfail REGR. vs. 112664

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
 build-arm64-libvirt   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
 build-arm64-pvops 2 hosts-allocate  broken like 112664
 build-arm64-xsm   2 hosts-allocate  broken like 112664
 build-arm64   2 hosts-allocate  broken like 112664
 build-arm64-pvops 3 capture-logsbroken like 112664
 build-arm64-xsm   3 capture-logsbroken like 112664
 build-arm64   3 capture-logsbroken like 112664
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 112664
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 112664
 build-amd64-prev  7 xen-build/dist-test  fail   never pass
 test-amd64-amd64-xl-pvh-intel 15 guest-saverestorefail  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-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  12 guest-start  fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 build-i386-prev   7 xen-build/dist-test  fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-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-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  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-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-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-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-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-examine  7 reboot   fail REGR. vs. 110515
 test-amd64-amd64-xl-qemut-debianhvm-amd64  7 xen-bootfail REGR. vs. 110515
 test-amd64-amd64-i386-pvgrub  7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-libvirt  7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-qemuu-nested-intel  7 xen-boot  fail REGR. vs. 110515
 test-amd64-amd64-amd64-pvgrub  7 xen-bootfail REGR. vs. 110515
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
110515
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. 
vs. 110515
 test-amd64-amd64-libvirt-pair 10 xen-boot/src_host   fail REGR. vs. 110515
 test-amd64-amd64-libvirt-pair 11 xen-boot/dst_host   fail REGR. vs. 110515
 test-amd64-amd64-libvirt-vhd  7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-libvirt-xsm  7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-xl-xsm   7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-xl-qcow2 7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-xl-pvh-intel  7 xen-bootfail REGR. vs. 110515
 test-amd64-amd64-rumprun-amd64  7 xen-boot   fail REGR. vs. 110515
 test-amd64-amd64-pygrub   7 xen-boot fail REGR. vs. 110515
 test-amd64-i386-libvirt  10 debian-install   fail REGR. vs. 110515
 test-amd64-amd64-xl-multivcpu 10 debian-install  fail REGR. vs. 110515
 test-amd64-i386-pair 16 debian-install/dst_host  fail REGR. vs. 110515
 test-amd64-i386-xl   10 debian-install   fail REGR. vs. 110515
 test-amd64-i386-libvirt-xsm  10 debian-install   fail REGR. vs. 110515
 test-amd64-i386-libvirt-pair 16 debian-install/dst_host  fail REGR. vs. 110515
 test-amd64-i386-xl-xsm   10 debian-install   fail REGR. vs. 110515
 test-amd64-amd64-xl-pvh-amd  10 debian-install   fail REGR. vs. 110515
 test-amd64-amd64-xl-credit2  10 debian-install   fail REGR. vs. 110515
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 
110515
 test-armhf-armhf-xl-credit2  10 debian-install   fail REGR. vs. 110515
 test-armhf-armhf-libvirt-xsm 10 debian-install   fail REGR. vs. 110515
 test-armhf-armhf-libvirt 10 debian-install   fail REGR. vs. 110515
 test-armhf-armhf-xl-cubietruck 10 debian-install fail REGR. vs. 110515
 test-armhf-armhf-xl-multivcpu 10 debian-install  fail REGR. vs. 110515
 test-armhf-armhf-xl-xsm  10 debian-install   fail REGR. vs. 110515
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
110515
 test-amd64-amd64-xl   7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-pair10 xen-boot/src_hostfail REGR. vs. 110515
 test-amd64-amd64-pair11 xen-boot/dst_hostfail REGR. vs. 110515
 test-armhf-armhf-xl  10 debian-install   fail REGR. vs. 110515
 test-armhf-armhf-xl-arndale  10 debian-install   fail REGR. vs. 110515
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. 
vs. 110515

Regressions which are regarded as allowable (not blocking):
 build-arm64-pvops 2 hosts-allocate broken REGR. vs. 110515
 build-arm64-xsm   2 hosts-allocate broken REGR. vs. 110515
 build-arm64   2 hosts-allocate broken REGR. vs. 110515
 test-armhf-armhf-xl-rtds 10 debian-install   fail REGR. vs. 110515

Tests which did not succeed, but are not blocking:
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 3 capture-logs  broken blocked in 110515
 build-arm64-xsm   3 capture-logs  broken blocked in 110515
 build-arm64   3 capture-logs  broken blocked in 110515
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 110515
 test-amd64-i386-xl-qemuu-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
 

Re: [Xen-devel] [PATCH v3 3/6] xen: RCU/x86/ARM: discount CPUs that were idle when grace period started.

[Dario Faggioli]

Il 22 Ago 2017 14:59, Jan Beulich  ha scritto:
>>> On 18.08.17 at 20:04,  wrote:
> Changes from v2:
> * initialize idle_cpumask to "all clear", i.e., all the CPUs are busy;
>   they'll clear their bit out themselves as soon as the run the idle
>   loop (pretty soon anyway).

Just to make sure I correctly understand this - you really mean
"they'll set their bit themselves ..."?

Err.. yes, that's what I meant indeed, sorry!

Dario


Jan


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

[Xen-devel] [xen-4.6-testing test] 112786: regressions - FAIL

[osstest service owner]

flight 112786 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112786/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-xtf-amd64-amd64-1 48 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 112661

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stopfail REGR. vs. 112661
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stopfail REGR. vs. 112661

Tests which did not succeed, but are not blocking:
 test-xtf-amd64-amd64-4  48 xtf/test-hvm64-lbr-tsx-vmentry fail like 112648
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 112661
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 112661
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 112661
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 112661
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 112661
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 112661
 test-amd64-amd64-xl-pvh-intel 15 guest-saverestorefail  never pass
 test-xtf-amd64-amd64-5   70 xtf/test-pv32pae-xsa-194 fail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-xtf-amd64-amd64-3   70 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-4   70 xtf/test-pv32pae-xsa-194 fail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-xl-pvh-amd  12 guest-start  fail   never pass
 test-xtf-amd64-amd64-2   70 xtf/test-pv32pae-xsa-194 fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail 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-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-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-xtf-amd64-amd64-1   70 xtf/test-pv32pae-xsa-194 fail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-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-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail 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-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-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-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 xen  b4660b4d4a35edac715c003c84326de2b0fa4f47
baseline version:
 xen  5ae011e6620fb3fdc1127c84873718ada4589e1c

Last test of basis   112661  2017-08-16 06:14:11 Z6 days
Failing since112683  2017-08-17 13:53:31 Z5 days5 attempts
Testing same since   112786  2017-08-21 15:03:13 Z1 days1 attempts


People who touched revisions under test:
  Jan 

Re: [Xen-devel] [PATCH 5/6] libxl: support mapping static shared memory areas during domain creation

[Stefano Stabellini]

On Wed, 23 Aug 2017, Zhongze Liu wrote:
> Add libxl__sshm_add to map shared pages from one DomU to another, The mapping
> process involves the follwing steps:
> 
>   * Set defaults and check for further errors in the static_shm configs:
> overlapping areas, invalid ranges, duplicated master domain,
> no master domain etc.
>   * Write infomation of static shared memory areas into the appropriate
> xenstore paths.
>   * use xc_domain_add_to_physmap_batch to do the page sharing.
> 
> Temporarily mark this as unsupported on x86 because calling p2m_add_foregin on
> two domU's is currently not allowd on x86 (see the comments in
> x86/mm/p2m.c:p2m_add_foregin for more details).
> 
> This is for the proposal "Allow setting up shared memory areas between VMs
> from xl config file" (see [1]).
> 
> [1] https://lists.xenproject.org/archives/html/xen-devel/2017-07/msg03047.html
> 
> Signed-off-by: Zhongze Liu 
> 
> Cc: Andrew Cooper 
> Cc: George Dunlap 
> Cc: Ian Jackson 
> Cc: Jan Beulich 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Stefano Stabellini 
> Cc: Tim Deegan 
> Cc: Wei Liu 
> Cc: Julien Grall 
> Cc: xen-devel@lists.xen.org
> ---
>  tools/libxl/Makefile |   2 +-
>  tools/libxl/libxl_arch.h |   6 +
>  tools/libxl/libxl_arm.c  |  15 ++
>  tools/libxl/libxl_create.c   |  27 
>  tools/libxl/libxl_internal.h |  14 ++
>  tools/libxl/libxl_sshm.c | 336 
> +++
>  tools/libxl/libxl_x86.c  |  18 +++
>  tools/libxl/libxl_xshelp.c   |   8 ++
>  8 files changed, 425 insertions(+), 1 deletion(-)
>  create mode 100644 tools/libxl/libxl_sshm.c
> 
> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
> index 3b63fb2cad..fd624b28f3 100644
> --- a/tools/libxl/Makefile
> +++ b/tools/libxl/Makefile
> @@ -138,7 +138,7 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_create.o 
> libxl_dm.o libxl_pci.o \
>   libxl_dom_suspend.o libxl_dom_save.o libxl_usb.o \
>   libxl_vtpm.o libxl_nic.o libxl_disk.o libxl_console.o \
>   libxl_cpupool.o libxl_mem.o libxl_sched.o libxl_tmem.o \
> - libxl_9pfs.o libxl_domain.o \
> + libxl_9pfs.o libxl_domain.o libxl_sshm.o \
>  $(LIBXL_OBJS-y)
>  LIBXL_OBJS += libxl_genid.o
>  LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
> diff --git a/tools/libxl/libxl_arch.h b/tools/libxl/libxl_arch.h
> index 5e1fc6060e..1d681d8863 100644
> --- a/tools/libxl/libxl_arch.h
> +++ b/tools/libxl/libxl_arch.h
> @@ -71,6 +71,12 @@ int libxl__arch_extra_memory(libxl__gc *gc,
>   const libxl_domain_build_info *info,
>   uint64_t *out);
>  
> +_hidden
> +bool libxl__arch_domain_support_sshm(const libxl_domain_build_info *b_info);
> +
> +_hidden
> +int libxl__arch_domain_sshm_cachepolicy_setdefault(libxl_static_shm *sshm);
> +
>  #if defined(__i386__) || defined(__x86_64__)
>  
>  #define LAPIC_BASE_ADDRESS  0xfee0
> diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
> index d842d888eb..0975109c0c 100644
> --- a/tools/libxl/libxl_arm.c
> +++ b/tools/libxl/libxl_arm.c
> @@ -1065,6 +1065,21 @@ void libxl__arch_domain_build_info_acpi_setdefault(
>  libxl_defbool_setdefault(_info->acpi, false);
>  }
>  
> +bool libxl__arch_domain_support_sshm(const libxl_domain_build_info *b_info)
> +{
> +return true;
> +}
> +
> +int libxl__arch_domain_sshm_cachepolicy_setdefault(libxl_static_shm *sshm)
> +{
> +if (sshm->cache_policy == LIBXL_SSHM_CACHEPOLICY_UNKNOWN)
> +sshm->cache_policy = LIBXL_SSHM_CACHEPOLICY_ARM_NORMAL;
> +if (sshm->cache_policy >= LIBXL_SSHM_CACHEPOLICY_X86_NORMAL)
> +return ERROR_INVAL;
> +
> +return 0;
> +}
> +
>  /*
>   * Local variables:
>   * mode: C
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index 1158303e1a..8e5ec486d2 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -501,6 +501,14 @@ int libxl__domain_build(libxl__gc *gc,
>  ret = ERROR_INVAL;
>  goto out;
>  }
> +
> +/* the p2m has been setup, we could map the static shared memory now. */
> +ret = libxl__sshm_add(gc, domid, d_config->sshms, d_config->num_sshms);
> +if (ret != 0) {
> +LOG(ERROR, "failed to map static shared memory");
> +goto out;
> +}
> +
>  ret = libxl__build_post(gc, domid, info, state, vments, localents);
>  out:
>  return ret;
> @@ -918,6 +926,25 @@ static void initiate_domain_create(libxl__egc *egc,
>  goto error_out;
>  }
>  
> +if (d_config->num_sshms != 0 &&
> +!libxl__arch_domain_support_sshm(_config->b_info)) {
> +LOGD(ERROR, domid, 

Re: [Xen-devel] [PATCH 6/6] libxl: support unmapping static shared memory areas during domain destruction

[Stefano Stabellini]

On Wed, 23 Aug 2017, Zhongze Liu wrote:
> Add libxl__sshm_del to Unmap static shared memory areas mapped by
> libxl__sshm_add during domain creation. The unmapping process is:
> 
> * For a master: check if it still has living slaves: 1) if yes, mark its
>   status as "zombie", and don't destroy the information under
>   /local/static_shm; 2) if no, simply cleanup related xs entries
> * For a slave: unmap the shared pages, and cleanup related xs entries. If
>   this is the only slave, and it's master is in zombie state, also cleanup
>   the master entries.
> 
> This is for the proposal "Allow setting up shared memory areas between VMs
> from xl config file" (see [1]).
> 
> [1] https://lists.xenproject.org/archives/html/xen-devel/2017-07/msg03047.html
> 
> Signed-off-by: Zhongze Liu 
> 
> Cc: Ian Jackson 
> Cc: Wei Liu 
> Cc: Stefano Stabellini 
> Cc: Julien Grall 
> Cc: xen-devel@lists.xen.org
> ---
>  tools/libxl/libxl_domain.c   |   5 ++
>  tools/libxl/libxl_internal.h |   2 +
>  tools/libxl/libxl_sshm.c | 125 
> +++
>  3 files changed, 132 insertions(+)
> 
> diff --git a/tools/libxl/libxl_domain.c b/tools/libxl/libxl_domain.c
> index 08eccd082b..73ac856fb4 100644
> --- a/tools/libxl/libxl_domain.c
> +++ b/tools/libxl/libxl_domain.c
> @@ -1028,6 +1028,11 @@ void libxl__destroy_domid(libxl__egc *egc, 
> libxl__destroy_domid_state *dis)
>  goto out;
>  }
>  
> +rc = libxl__sshm_del(gc, domid);
> +if (rc) {
> +LOGD(ERROR, domid, "Deleting static shm failed.");
> +}
> +
>  if (libxl__device_pci_destroy_all(gc, domid) < 0)
>  LOGD(ERROR, domid, "Pci shutdown failed");
>  rc = xc_domain_pause(ctx->xch, domid);
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 74bc0acb21..648eaee8c2 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -4361,6 +4361,8 @@ static inline bool libxl__acpi_defbool_val(const 
> libxl_domain_build_info *b_info
>  _hidden int libxl__sshm_add(libxl__gc *gc, uint32_t domid,
>  libxl_static_shm *sshm, int len);
>  
> +_hidden int libxl__sshm_del(libxl__gc *gc, uint32_t domid);
> +
>  _hidden int libxl__sshm_check_overlap(libxl__gc *gc, uint32_t domid,
>libxl_static_shm *sshms, int len);
>  _hidden int libxl__sshm_setdefault(libxl__gc *gc, uint32_t domid,
> diff --git a/tools/libxl/libxl_sshm.c b/tools/libxl/libxl_sshm.c
> index e16c24ccb9..417a4cd0a4 100644
> --- a/tools/libxl/libxl_sshm.c
> +++ b/tools/libxl/libxl_sshm.c
> @@ -79,6 +79,131 @@ int libxl__sshm_check_overlap(libxl__gc *gc, uint32_t 
> domid,
>  return 0;
>  }
>  
> +/* Delete sshm master infomation from xenstore. If there are still living
> + * slaves, mark the master as in zombie state, but do not delete it,
> + * and it will be totally deleted later after all slaves are gone */
> +static void libxl__sshm_del_master(libxl__gc *gc, xs_transaction_t xt,
> +   uint32_t domid, const char *id)
> +{
> +char *sshm_path;
> +
> +sshm_path = libxl__xs_get_sshmpath(gc, id);
> +
> +/* we know that domid can't be both a master and a slave for one id
> + * (enforced in the *_add_master() and *_add_slave() code),
> + * so the number of slaves won't change during iteration. Simply check
> + * sshm_path/slaves to tell if there are still living slaves. */
> +if (libxl__xs_read(gc, xt, GCSPRINTF("%s/slaves", sshm_path))) {

Is it possible that "slaves" is present but empty? What does
libxl__xs_read return in that case?


> +SSHM_ERROR(domid, id,
> +   "there are living slaves, won't be totally destroyed");
> +
> +libxl__xs_write_checked(gc, xt,
> +GCSPRINTF("%s/status", sshm_path),
> +"zombie");
> +} else {
> +libxl__xs_path_cleanup(gc, xt, sshm_path);
> +}
> +
> +return;
> +}
> +
> +static void libxl__sshm_do_unmap(libxl__gc *gc, uint32_t domid, const char 
> *id,
> + uint64_t begin, uint64_t end)
> +{
> +begin >>= 12;
> +end >>= 12;
> +for (; begin < end; ++begin) {
> +if (xc_domain_remove_from_physmap(CTX->xch, domid, begin)) {
> +SSHM_ERROR(domid, id,
> +   "unable to unmap shared page at 0x%"PRIx64".",
> +   begin);
> +}
> +}
> +}
> +
> +static void libxl__sshm_del_slave(libxl__gc *gc, xs_transaction_t xt,
> +  uint32_t domid, const char *id, bool 
> isretry)
> +{
> +char *sshm_path, *slave_path;
> +char *master_stat, *mdomid_str, *begin_str, *end_str;
> +uint64_t begin, end;
> +uint32_t master_domid;
> +
> +sshm_path = libxl__xs_get_sshmpath(gc, id);
> +

Re: [Xen-devel] [PATCH 3/6] libxl:xl: add parsing code to parse "libxl_static_sshm" from xl config files

[Stefano Stabellini]

On Wed, 23 Aug 2017, Zhongze Liu wrote:
> Add the parsing utils for the newly introduced libxl_static_sshm struct
> to the libxl/libxlu_* family. And add realated parsing code in xl to
> parse the struct from xl config files. This is for the proposal "Allow
> setting up shared memory areas between VMs from xl config file" (see [1]).
> 
> [1] https://lists.xenproject.org/archives/html/xen-devel/2017-07/msg03047.html
> 
> Signed-off-by: Zhongze Liu 
> 
> Cc: Andrew Cooper 
> Cc: George Dunlap 
> Cc: Ian Jackson 
> Cc: Jan Beulich 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Stefano Stabellini 
> Cc: Tim Deegan 
> Cc: Wei Liu 
> Cc: Julien Grall 
> Cc: xen-devel@lists.xen.org
> ---
>  tools/libxl/Makefile  |   2 +-
>  tools/libxl/libxlu_sshm.c | 210 
> ++
>  tools/libxl/libxlutil.h   |   6 ++
>  tools/xl/xl_parse.c   |  24 +-
>  4 files changed, 240 insertions(+), 2 deletions(-)
>  create mode 100644 tools/libxl/libxlu_sshm.c
> 
> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
> index 082af8f716..3b63fb2cad 100644
> --- a/tools/libxl/Makefile
> +++ b/tools/libxl/Makefile
> @@ -175,7 +175,7 @@ AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h _libxl_list.h 
> _paths.h \
>  AUTOSRCS= libxlu_cfg_y.c libxlu_cfg_l.c
>  AUTOSRCS += _libxl_save_msgs_callout.c _libxl_save_msgs_helper.c
>  LIBXLU_OBJS = libxlu_cfg_y.o libxlu_cfg_l.o libxlu_cfg.o \
> - libxlu_disk_l.o libxlu_disk.o libxlu_vif.o libxlu_pci.o
> + libxlu_disk_l.o libxlu_disk.o libxlu_vif.o libxlu_pci.o libxlu_sshm.o
>  $(LIBXLU_OBJS): CFLAGS += $(CFLAGS_libxenctrl) # For xentoollog.h
>  
>  $(TEST_PROG_OBJS) _libxl.api-for-check: CFLAGS += $(CFLAGS_libxentoollog)
> diff --git a/tools/libxl/libxlu_sshm.c b/tools/libxl/libxlu_sshm.c
> new file mode 100644
> index 00..8647665213
> --- /dev/null
> +++ b/tools/libxl/libxlu_sshm.c
> @@ -0,0 +1,210 @@
> +#include "libxl_osdeps.h" /* must come before any other headers */
> +#include "libxlu_internal.h"
> +
> +#include 
> +
> +#define PARAM_RE(EXPR) "^\\s*" EXPR "\\s*(,|$)"
> +#define WORD_RE "([_a-zA-Z0-9]+)"
> +#define EQU_RE PARAM_RE(WORD_RE "\\s*=\\s*" WORD_RE)
> +
> +#define PAGE_SIZE_MASK ((uint64_t)0xfff)

You can probably use XC_PAGE_MASK that is already defined?
Otherwise I would name this XLU_PAGE_MASK and move the definition to one
of the libxlu headers.

I am not the most qualified person to review xlu code, but this patch
looks OK to me.


> +#define RET_INVAL(msg, curr_str)  do {  \
> +xlu__sshm_err(cfg, msg, curr_str);  \
> +rc = EINVAL;\
> +goto out;   \
> +} while(0)
> +
> +/* set a member in libxl_static_shm and report an error if it's respecified,
> + * @curr_str indicates the head of the remaining string. */
> +#define SET_VAL(var, name, type, value, curr_str)  do { \
> +if ((var) != LIBXL_SSHM_##type##_UNKNOWN && (var) != value) {   \
> +RET_INVAL("\"" name "\" respecified", curr_str);\
> +}   \
> +(var) = value;  \
> +} while(0)
> +
> +
> +static void xlu__sshm_err(XLU_Config *cfg, const char *msg,
> +  const char *curr_str) {
> +fprintf(cfg->report,
> +"%s: config parsing error in shared_memory: %s at '%s'\n",
> +cfg->config_source, msg, curr_str);
> +}
> +
> +static int parse_prot(XLU_Config *cfg, char *str, libxl_sshm_prot *prot)
> +{
> +int rc;
> +libxl_sshm_prot new_prot;
> +
> +if (!strcmp(str, "rw")) {
> +new_prot = LIBXL_SSHM_PROT_RW;
> +} else {
> +RET_INVAL("invalid permission flags", str);
> +}
> +
> +SET_VAL(*prot, "permission flags", PROT, new_prot, str);
> +
> +rc = 0;
> +
> + out:
> +return rc;
> +}
> +
> +static int parse_cachepolicy(XLU_Config *cfg, char *str,
> + libxl_sshm_cachepolicy *policy)
> +{
> +int rc;
> +libxl_sshm_cachepolicy new_policy;
> +
> +if (!strcmp(str, "ARM_normal")) {
> +new_policy = LIBXL_SSHM_CACHEPOLICY_ARM_NORMAL;
> +} else if (!strcmp(str, "x86_normal")) {
> +new_policy = LIBXL_SSHM_CACHEPOLICY_X86_NORMAL;
> +} else {
> +RET_INVAL("invalid cache policy", str);
> +}
> +
> +SET_VAL(*policy, "cache policy", CACHEPOLICY, new_policy, str);
> +rc = 0;
> +
> + out:
> +return rc;
> +}
> +
> +/* handle key = value pairs */
> +static int handle_equ(XLU_Config *cfg, char *key, char *val,
> +  libxl_static_shm *sshm)
> +{
> +int rc;
> +
> +if (!strcmp(key, "id")) {

Re: [Xen-devel] [PATCH] xen/events: events_fifo: Don't use {get, put}_cpu() in xen_evtchn_fifo_init()

[Boris Ostrovsky]

On 08/22/2017 12:15 PM, Julien Grall wrote:
> Hi,
>
> Gentle ping. This patch was reviewed but not queued. Are we waiting
> for other reviewed?

Applied to for-linus-4.14.

-boris


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

Re: [Xen-devel] [PATCH 2/6] libxl: introduce a new structure to represent static shared memory regions

[Stefano Stabellini]

On Wed, 23 Aug 2017, Zhongze Liu wrote:
> Add a new structure to the IDL famliy to represent static shared memory 
> regions,
  ^ family


> as proposed in the proposal "Allow setting up shared memory areas between VMs
> from xl config file" (see [1]).
> 
> [1] https://lists.xenproject.org/archives/html/xen-devel/2017-07/msg03047.html
> 
> Signed-off-by: Zhongze Liu 
> 
> Cc: Wei Liu 
> Cc: Ian Jackson 
> Cc: Stefano Stabellini 
> Cc: Julien Grall 
> Cc: xen-devel@lists.xen.org
> ---
>  tools/libxl/libxl.h |  4 
>  tools/libxl/libxl_types.idl | 36 
>  2 files changed, 36 insertions(+), 4 deletions(-)
> 
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index 229e289750..3ee788642f 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -2237,6 +2237,10 @@ int libxl_fd_set_nonblock(libxl_ctx *ctx, int fd, int 
> nonblock);
>  int libxl_qemu_monitor_command(libxl_ctx *ctx, uint32_t domid,
> const char *command_line, char **output);
>  
> +/* Constants for libxl_static_shm */
> +#define LIBXL_SSHM_RANGE_UNKNOWN UINT64_MAX
> +#define LIBXL_SSHM_ID_MAXLEN128
> +
>  #include 
>  
>  #endif /* LIBXL_H */
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index 6e80d36256..6c9e79c05d 100644
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -472,7 +472,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
>  ("blkdev_start",string),
>  
>  ("vnuma_nodes", Array(libxl_vnode_info, "num_vnuma_nodes")),
> -
> +

Although your code style corrections are appropriate, usually we do them
in separate patches to separate them out from more meaningful changes.
However, different maintainers have different styles, so Wei might be OK
with this.

In any case:

Reviewed-by: Stefano Stabellini 


>  ("device_model_version", libxl_device_model_version),
>  ("device_model_stubdomain", libxl_defbool),
>  # if you set device_model you must set device_model_version too
> @@ -494,7 +494,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
>  ("ioports",  Array(libxl_ioport_range, "num_ioports")),
>  ("irqs", Array(uint32, "num_irqs")),
>  ("iomem",Array(libxl_iomem_range, "num_iomem")),
> -("claim_mode",libxl_defbool),
> +("claim_mode",   libxl_defbool),
>  ("event_channels",   uint32),
>  ("kernel",   string),
>  ("cmdline",  string),
> @@ -543,10 +543,10 @@ libxl_domain_build_info = Struct("domain_build_info",[
> ("keymap",   string),
> ("sdl",  libxl_sdl_info),
> ("spice",
> libxl_spice_info),
> -   
> +
> ("gfx_passthru", libxl_defbool),
> ("gfx_passthru_kind", 
> libxl_gfx_passthru_kind),
> -   
> +
> ("serial",   string),
> ("boot", string),
> ("usb",  libxl_defbool),
> @@ -779,6 +779,33 @@ libxl_device_channel = Struct("device_channel", [
> ])),
>  ])
>  
> +libxl_sshm_cachepolicy = Enumeration("sshm_cachepolicy", [
> +(-1, "UNKNOWN"),
> +(0,  "ARM_NORMAL"),  # ARM policies should be < 32
> +(32,  "X86_NORMAL"), # X86 policies should be >= 32
> +], init_val = "LIBXL_SSHM_CHCHE_POLICY_UNKNOWN")
> +
> +libxl_sshm_prot = Enumeration("sshm_prot", [
> +(-1, "UNKNOWN"),
> +(3,  "RW"),
> +], init_val = "LIBXL_SSHM_PROT_UNKNOWN")
> +
> +libxl_sshm_role = Enumeration("sshm_role", [
> +(-1, "UNKNOWN"),
> +(0,  "MASTER"),
> +(1,  "SLAVE"),
> +], init_val = "LIBXL_SSHM_ROLE_UNKNOWN")
> +
> +libxl_static_shm = Struct("static_shm", [
> +("id", string),
> +("offset", uint64, {'init_val': 'LIBXL_SSHM_RANGE_UNKNOWN'}),
> +("begin", uint64, {'init_val': 'LIBXL_SSHM_RANGE_UNKNOWN'}),
> +("end", uint64, {'init_val': 'LIBXL_SSHM_RANGE_UNKNOWN'}),
> +("prot", libxl_sshm_prot, {'init_val': 'LIBXL_SSHM_PROT_UNKNOWN'}),
> +("cache_policy", libxl_sshm_cachepolicy, {'init_val': 
> 'LIBXL_SSHM_CACHEPOLICY_UNKNOWN'}),
> +("role", libxl_sshm_role, {'init_val': 'LIBXL_SSHM_ROLE_UNKNOWN'}),
> +])
> +
>  libxl_domain_config = Struct("domain_config", [
>  ("c_info", libxl_domain_create_info),
>  ("b_info", libxl_domain_build_info),
> @@ -797,6 +824,7 @@ libxl_domain_config = Struct("domain_config", [
>  ("channels", Array(libxl_device_channel, "num_channels")),

Re: [Xen-devel] [PATCH 4/6] xsm: flask: change the interface and default policy for xsm_map_gmfn_foregin

[Stefano Stabellini]

On Wed, 23 Aug 2017, Zhongze Liu wrote:
> The original xsm_map_gmfn_foregin policy checks if source domain has the 
> proper
> privileges over the target domain. Under this policy, it's not allowed if a 
> Dom0
> wants to map pages from one DomU to another, this restricts some useful yet 
> not
> dangerous usages of the API, such as sharing pages among DomU's by calling
> XENMEM_add_to_physmap from Dom0.
> 
> Change the policy to: IIF current domain has the proper privilege on the
^ IFF


> target domain and source domain, grant the access.
> 
> References to this xsm check have also been updated to pass the current
> domain as a new parameter.
> 
> This is for the proposal "Allow setting up shared memory areas between VMs
> from xl config file" (see [1]).
> 
> [1] https://lists.xenproject.org/archives/html/xen-devel/2017-07/msg03047.html
> 
> Signed-off-by: Zhongze Liu 
> 
> Cc: Stefano Stabellini 
> Cc: Julien Grall 
> Cc: George Dunlap 
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> Cc: Daniel De Graaf 
> Cc: xen-devel@lists.xen.org
> ---
>  xen/arch/arm/mm.c   | 2 +-
>  xen/arch/x86/mm/p2m.c   | 2 +-
>  xen/include/xsm/dummy.h | 6 --
>  xen/include/xsm/xsm.h   | 7 ---
>  xen/xsm/flask/hooks.c   | 6 --
>  5 files changed, 14 insertions(+), 9 deletions(-)
> 
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index a810a056d7..9ec78d8c03 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -1284,7 +1284,7 @@ int xenmem_add_to_physmap_one(
>  return -EINVAL;
>  }
>  
> -rc = xsm_map_gmfn_foreign(XSM_TARGET, d, od);
> +rc = xsm_map_gmfn_foreign(XSM_TARGET, current->domain, d, od);
>  if ( rc )
>  {
>  rcu_unlock_domain(od);
> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
> index e8a57d118c..a547fd00c0 100644
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -2545,7 +2545,7 @@ int p2m_add_foreign(struct domain *tdom, unsigned long 
> fgfn,
>  if ( tdom == fdom )
>  goto out;
>  
> -rc = xsm_map_gmfn_foreign(XSM_TARGET, tdom, fdom);
> +rc = xsm_map_gmfn_foreign(XSM_TARGET, current->domain, tdom, fdom);
>  if ( rc )
>  goto out;
>  
> diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
> index 62fcea6f04..28dbc6f2a2 100644
> --- a/xen/include/xsm/dummy.h
> +++ b/xen/include/xsm/dummy.h
> @@ -525,10 +525,12 @@ static XSM_INLINE int 
> xsm_remove_from_physmap(XSM_DEFAULT_ARG struct domain *d1,
>  return xsm_default_action(action, d1, d2);
>  }
>  
> -static XSM_INLINE int xsm_map_gmfn_foreign(XSM_DEFAULT_ARG struct domain *d, 
> struct domain *t)
> +static XSM_INLINE int xsm_map_gmfn_foreign(XSM_DEFAULT_ARG struct domain *cd,
> +   struct domain *d, struct domain 
> *t)
>  {
>  XSM_ASSERT_ACTION(XSM_TARGET);
> -return xsm_default_action(action, d, t);
> +return xsm_default_action(action, cd, d) ||
> +xsm_default_action(action, cd, t);

We need to preserve the returned errors:

  rc = xsm_default_action(action, cd, d);
  if (rc) return rc;
  return xsm_default_action(action, cd, t);



>  }
>  
>  static XSM_INLINE int xsm_hvm_param(XSM_DEFAULT_ARG struct domain *d, 
> unsigned long op)
> diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
> index 60c0fd6a62..a20654a803 100644
> --- a/xen/include/xsm/xsm.h
> +++ b/xen/include/xsm/xsm.h
> @@ -85,7 +85,7 @@ struct xsm_operations {
>  int (*memory_pin_page) (struct domain *d1, struct domain *d2, struct 
> page_info *page);
>  int (*add_to_physmap) (struct domain *d1, struct domain *d2);
>  int (*remove_from_physmap) (struct domain *d1, struct domain *d2);
> -int (*map_gmfn_foreign) (struct domain *d, struct domain *t);
> +int (*map_gmfn_foreign) (struct domain *cd, struct domain *d, struct 
> domain *t);
>  int (*claim_pages) (struct domain *d);
>  
>  int (*console_io) (struct domain *d, int cmd);
> @@ -372,9 +372,10 @@ static inline int xsm_remove_from_physmap(xsm_default_t 
> def, struct domain *d1,
>  return xsm_ops->remove_from_physmap(d1, d2);
>  }
>  
> -static inline int xsm_map_gmfn_foreign (xsm_default_t def, struct domain *d, 
> struct domain *t)
> +static inline int xsm_map_gmfn_foreign (xsm_default_t def, struct domain *cd,
> +struct domain *d, struct domain *t)
>  {
> -return xsm_ops->map_gmfn_foreign(d, t);
> +return xsm_ops->map_gmfn_foreign(cd, d, t);
>  }
>  
>  static inline int xsm_claim_pages(xsm_default_t def, struct domain *d)
> diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
> index 91146275bb..3408b6b9e1 100644
> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -1165,9 +1165,11 @@ static int flask_remove_from_physmap(struct 

[Xen-devel] [PATCH 4.12 27/41] xen-blkfront: use a right index when checking requests

[Greg Kroah-Hartman]

4.12-stable review patch.  If anyone has any objections, please let me know.

--

From: Munehisa Kamata 

commit b15bd8cb37598afb2963f7eb9e2de468d2d60a2f upstream.

Since commit d05d7f40791c ("Merge branch 'for-4.8/core' of
git://git.kernel.dk/linux-block") and 3fc9d690936f ("Merge branch
'for-4.8/drivers' of git://git.kernel.dk/linux-block"), blkfront_resume()
has been using an index for iterating ring_info to check request when
iterating blk_shadow in an inner loop. This seems to have been
accidentally introduced during the massive rewrite of the block layer
macros in the commits.

This may cause crash like this:

[11798.057074] BUG: unable to handle kernel NULL pointer dereference at 
0048
[11798.058832] IP: [] blkfront_resume+0x10a/0x610

[11798.061063] Call Trace:
[11798.061063]  [] xenbus_dev_resume+0x53/0x140
[11798.061063]  [] ? xenbus_dev_probe+0x150/0x150
[11798.061063]  [] dpm_run_callback+0x3e/0x110
[11798.061063]  [] device_resume+0x88/0x190
[11798.061063]  [] dpm_resume+0x100/0x2d0
[11798.061063]  [] dpm_resume_end+0x11/0x20
[11798.061063]  [] do_suspend+0xe8/0x1a0
[11798.061063]  [] shutdown_handler+0xfd/0x130
[11798.061063]  [] ? split+0x110/0x110
[11798.061063]  [] xenwatch_thread+0x86/0x120
[11798.061063]  [] ? prepare_to_wait_event+0x110/0x110
[11798.061063]  [] kthread+0xd7/0xf0
[11798.061063]  [] ? kfree+0x121/0x170
[11798.061063]  [] ? kthread_park+0x60/0x60
[11798.061063]  [] ?  call_usermodehelper_exec_work+0xb0/0xb0
[11798.061063]  [] ?  
call_usermodehelper_exec_async+0x13a/0x140
[11798.061063]  [] ret_from_fork+0x25/0x30

Use the right index in the inner loop.

Fixes: d05d7f40791c ("Merge branch 'for-4.8/core' of 
git://git.kernel.dk/linux-block")
Fixes: 3fc9d690936f ("Merge branch 'for-4.8/drivers' of 
git://git.kernel.dk/linux-block")
Signed-off-by: Munehisa Kamata 
Reviewed-by: Thomas Friebel 
Reviewed-by: Eduardo Valentin 
Reviewed-by: Boris Ostrovsky 
Cc: Juergen Gross 
Cc: Konrad Rzeszutek Wilk 
Reviewed-by: Roger Pau Monne 
Cc: xen-de...@lists.xenproject.org
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/block/xen-blkfront.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -2119,9 +2119,9 @@ static int blkfront_resume(struct xenbus
/*
 * Get the bios in the request so we can re-queue them.
 */
-   if (req_op(shadow[i].request) == REQ_OP_FLUSH ||
-   req_op(shadow[i].request) == REQ_OP_DISCARD ||
-   req_op(shadow[i].request) == REQ_OP_SECURE_ERASE ||
+   if (req_op(shadow[j].request) == REQ_OP_FLUSH ||
+   req_op(shadow[j].request) == REQ_OP_DISCARD ||
+   req_op(shadow[j].request) == REQ_OP_SECURE_ERASE ||
shadow[j].request->cmd_flags & REQ_FUA) {
/*
 * Flush operations don't contain bios, so



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

[Xen-devel] [PATCH 4.9 18/27] xen-blkfront: use a right index when checking requests

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Munehisa Kamata 

commit b15bd8cb37598afb2963f7eb9e2de468d2d60a2f upstream.

Since commit d05d7f40791c ("Merge branch 'for-4.8/core' of
git://git.kernel.dk/linux-block") and 3fc9d690936f ("Merge branch
'for-4.8/drivers' of git://git.kernel.dk/linux-block"), blkfront_resume()
has been using an index for iterating ring_info to check request when
iterating blk_shadow in an inner loop. This seems to have been
accidentally introduced during the massive rewrite of the block layer
macros in the commits.

This may cause crash like this:

[11798.057074] BUG: unable to handle kernel NULL pointer dereference at 
0048
[11798.058832] IP: [] blkfront_resume+0x10a/0x610

[11798.061063] Call Trace:
[11798.061063]  [] xenbus_dev_resume+0x53/0x140
[11798.061063]  [] ? xenbus_dev_probe+0x150/0x150
[11798.061063]  [] dpm_run_callback+0x3e/0x110
[11798.061063]  [] device_resume+0x88/0x190
[11798.061063]  [] dpm_resume+0x100/0x2d0
[11798.061063]  [] dpm_resume_end+0x11/0x20
[11798.061063]  [] do_suspend+0xe8/0x1a0
[11798.061063]  [] shutdown_handler+0xfd/0x130
[11798.061063]  [] ? split+0x110/0x110
[11798.061063]  [] xenwatch_thread+0x86/0x120
[11798.061063]  [] ? prepare_to_wait_event+0x110/0x110
[11798.061063]  [] kthread+0xd7/0xf0
[11798.061063]  [] ? kfree+0x121/0x170
[11798.061063]  [] ? kthread_park+0x60/0x60
[11798.061063]  [] ?  call_usermodehelper_exec_work+0xb0/0xb0
[11798.061063]  [] ?  
call_usermodehelper_exec_async+0x13a/0x140
[11798.061063]  [] ret_from_fork+0x25/0x30

Use the right index in the inner loop.

Fixes: d05d7f40791c ("Merge branch 'for-4.8/core' of 
git://git.kernel.dk/linux-block")
Fixes: 3fc9d690936f ("Merge branch 'for-4.8/drivers' of 
git://git.kernel.dk/linux-block")
Signed-off-by: Munehisa Kamata 
Reviewed-by: Thomas Friebel 
Reviewed-by: Eduardo Valentin 
Reviewed-by: Boris Ostrovsky 
Cc: Juergen Gross 
Cc: Konrad Rzeszutek Wilk 
Reviewed-by: Roger Pau Monne 
Cc: xen-de...@lists.xenproject.org
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/block/xen-blkfront.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -2112,9 +2112,9 @@ static int blkfront_resume(struct xenbus
/*
 * Get the bios in the request so we can re-queue them.
 */
-   if (req_op(shadow[i].request) == REQ_OP_FLUSH ||
-   req_op(shadow[i].request) == REQ_OP_DISCARD ||
-   req_op(shadow[i].request) == REQ_OP_SECURE_ERASE ||
+   if (req_op(shadow[j].request) == REQ_OP_FLUSH ||
+   req_op(shadow[j].request) == REQ_OP_DISCARD ||
+   req_op(shadow[j].request) == REQ_OP_SECURE_ERASE ||
shadow[j].request->cmd_flags & REQ_FUA) {
/*
 * Flush operations don't contain bios, so



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

[Xen-devel] [xen-unstable-smoke test] 112825: tolerable trouble: broken/pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 2 hosts-allocate  broken like 112816
 build-arm64   2 hosts-allocate  broken like 112816
 build-arm64-pvops 3 capture-logsbroken like 112816
 build-arm64   3 capture-logsbroken like 112816
 test-amd64-amd64-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

version targeted for testing:
 xen  4a0485c3d343e1c582fa824e4896b9b613a14efe
baseline version:
 xen  0c5f2f9cefacd0881b86abbe36e231815cef7735

Last test of basis   112816  2017-08-22 09:18:11 Z0 days
Testing same since   112825  2017-08-22 16:03:07 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Bernd Kuhls 
  Igor Druzhinin 
  Jan Beulich 
  Thomas Petazzoni 
  Wei Liu 

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



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

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

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

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

broken-step build-arm64-pvops hosts-allocate
broken-step build-arm64 hosts-allocate
broken-step build-arm64-pvops capture-logs
broken-step build-arm64 capture-logs

Pushing revision :

+ branch=xen-unstable-smoke
+ revision=4a0485c3d343e1c582fa824e4896b9b613a14efe
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
4a0485c3d343e1c582fa824e4896b9b613a14efe
+ branch=xen-unstable-smoke
+ revision=4a0485c3d343e1c582fa824e4896b9b613a14efe
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.9-testing
+ '[' x4a0485c3d343e1c582fa824e4896b9b613a14efe = 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
++ : 

[Xen-devel] [PATCH 5/6] libxl: support mapping static shared memory areas during domain creation

[Zhongze Liu]

Add libxl__sshm_add to map shared pages from one DomU to another, The mapping
process involves the follwing steps:

  * Set defaults and check for further errors in the static_shm configs:
overlapping areas, invalid ranges, duplicated master domain,
no master domain etc.
  * Write infomation of static shared memory areas into the appropriate
xenstore paths.
  * use xc_domain_add_to_physmap_batch to do the page sharing.

Temporarily mark this as unsupported on x86 because calling p2m_add_foregin on
two domU's is currently not allowd on x86 (see the comments in
x86/mm/p2m.c:p2m_add_foregin for more details).

This is for the proposal "Allow setting up shared memory areas between VMs
from xl config file" (see [1]).

[1] https://lists.xenproject.org/archives/html/xen-devel/2017-07/msg03047.html

Signed-off-by: Zhongze Liu 

Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
Cc: Julien Grall 
Cc: xen-devel@lists.xen.org
---
 tools/libxl/Makefile |   2 +-
 tools/libxl/libxl_arch.h |   6 +
 tools/libxl/libxl_arm.c  |  15 ++
 tools/libxl/libxl_create.c   |  27 
 tools/libxl/libxl_internal.h |  14 ++
 tools/libxl/libxl_sshm.c | 336 +++
 tools/libxl/libxl_x86.c  |  18 +++
 tools/libxl/libxl_xshelp.c   |   8 ++
 8 files changed, 425 insertions(+), 1 deletion(-)
 create mode 100644 tools/libxl/libxl_sshm.c

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 3b63fb2cad..fd624b28f3 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -138,7 +138,7 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o 
libxl_pci.o \
libxl_dom_suspend.o libxl_dom_save.o libxl_usb.o \
libxl_vtpm.o libxl_nic.o libxl_disk.o libxl_console.o \
libxl_cpupool.o libxl_mem.o libxl_sched.o libxl_tmem.o \
-   libxl_9pfs.o libxl_domain.o \
+   libxl_9pfs.o libxl_domain.o libxl_sshm.o \
 $(LIBXL_OBJS-y)
 LIBXL_OBJS += libxl_genid.o
 LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
diff --git a/tools/libxl/libxl_arch.h b/tools/libxl/libxl_arch.h
index 5e1fc6060e..1d681d8863 100644
--- a/tools/libxl/libxl_arch.h
+++ b/tools/libxl/libxl_arch.h
@@ -71,6 +71,12 @@ int libxl__arch_extra_memory(libxl__gc *gc,
  const libxl_domain_build_info *info,
  uint64_t *out);
 
+_hidden
+bool libxl__arch_domain_support_sshm(const libxl_domain_build_info *b_info);
+
+_hidden
+int libxl__arch_domain_sshm_cachepolicy_setdefault(libxl_static_shm *sshm);
+
 #if defined(__i386__) || defined(__x86_64__)
 
 #define LAPIC_BASE_ADDRESS  0xfee0
diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index d842d888eb..0975109c0c 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -1065,6 +1065,21 @@ void libxl__arch_domain_build_info_acpi_setdefault(
 libxl_defbool_setdefault(_info->acpi, false);
 }
 
+bool libxl__arch_domain_support_sshm(const libxl_domain_build_info *b_info)
+{
+return true;
+}
+
+int libxl__arch_domain_sshm_cachepolicy_setdefault(libxl_static_shm *sshm)
+{
+if (sshm->cache_policy == LIBXL_SSHM_CACHEPOLICY_UNKNOWN)
+sshm->cache_policy = LIBXL_SSHM_CACHEPOLICY_ARM_NORMAL;
+if (sshm->cache_policy >= LIBXL_SSHM_CACHEPOLICY_X86_NORMAL)
+return ERROR_INVAL;
+
+return 0;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 1158303e1a..8e5ec486d2 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -501,6 +501,14 @@ int libxl__domain_build(libxl__gc *gc,
 ret = ERROR_INVAL;
 goto out;
 }
+
+/* the p2m has been setup, we could map the static shared memory now. */
+ret = libxl__sshm_add(gc, domid, d_config->sshms, d_config->num_sshms);
+if (ret != 0) {
+LOG(ERROR, "failed to map static shared memory");
+goto out;
+}
+
 ret = libxl__build_post(gc, domid, info, state, vments, localents);
 out:
 return ret;
@@ -918,6 +926,25 @@ static void initiate_domain_create(libxl__egc *egc,
 goto error_out;
 }
 
+if (d_config->num_sshms != 0 &&
+!libxl__arch_domain_support_sshm(_config->b_info)) {
+LOGD(ERROR, domid, "static_shm is not supported by this domain type.");
+ret = ERROR_INVAL;
+goto error_out;
+}
+
+ret = libxl__sshm_check_overlap(gc, domid,
+d_config->sshms, d_config->num_sshms);
+if (ret) goto error_out;
+
+for (i = 0; i < 

[Xen-devel] [PATCH 6/6] libxl: support unmapping static shared memory areas during domain destruction

[Zhongze Liu]

Add libxl__sshm_del to Unmap static shared memory areas mapped by
libxl__sshm_add during domain creation. The unmapping process is:

* For a master: check if it still has living slaves: 1) if yes, mark its
  status as "zombie", and don't destroy the information under
  /local/static_shm; 2) if no, simply cleanup related xs entries
* For a slave: unmap the shared pages, and cleanup related xs entries. If
  this is the only slave, and it's master is in zombie state, also cleanup
  the master entries.

This is for the proposal "Allow setting up shared memory areas between VMs
from xl config file" (see [1]).

[1] https://lists.xenproject.org/archives/html/xen-devel/2017-07/msg03047.html

Signed-off-by: Zhongze Liu 

Cc: Ian Jackson 
Cc: Wei Liu 
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: xen-devel@lists.xen.org
---
 tools/libxl/libxl_domain.c   |   5 ++
 tools/libxl/libxl_internal.h |   2 +
 tools/libxl/libxl_sshm.c | 125 +++
 3 files changed, 132 insertions(+)

diff --git a/tools/libxl/libxl_domain.c b/tools/libxl/libxl_domain.c
index 08eccd082b..73ac856fb4 100644
--- a/tools/libxl/libxl_domain.c
+++ b/tools/libxl/libxl_domain.c
@@ -1028,6 +1028,11 @@ void libxl__destroy_domid(libxl__egc *egc, 
libxl__destroy_domid_state *dis)
 goto out;
 }
 
+rc = libxl__sshm_del(gc, domid);
+if (rc) {
+LOGD(ERROR, domid, "Deleting static shm failed.");
+}
+
 if (libxl__device_pci_destroy_all(gc, domid) < 0)
 LOGD(ERROR, domid, "Pci shutdown failed");
 rc = xc_domain_pause(ctx->xch, domid);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 74bc0acb21..648eaee8c2 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -4361,6 +4361,8 @@ static inline bool libxl__acpi_defbool_val(const 
libxl_domain_build_info *b_info
 _hidden int libxl__sshm_add(libxl__gc *gc, uint32_t domid,
 libxl_static_shm *sshm, int len);
 
+_hidden int libxl__sshm_del(libxl__gc *gc, uint32_t domid);
+
 _hidden int libxl__sshm_check_overlap(libxl__gc *gc, uint32_t domid,
   libxl_static_shm *sshms, int len);
 _hidden int libxl__sshm_setdefault(libxl__gc *gc, uint32_t domid,
diff --git a/tools/libxl/libxl_sshm.c b/tools/libxl/libxl_sshm.c
index e16c24ccb9..417a4cd0a4 100644
--- a/tools/libxl/libxl_sshm.c
+++ b/tools/libxl/libxl_sshm.c
@@ -79,6 +79,131 @@ int libxl__sshm_check_overlap(libxl__gc *gc, uint32_t domid,
 return 0;
 }
 
+/* Delete sshm master infomation from xenstore. If there are still living
+ * slaves, mark the master as in zombie state, but do not delete it,
+ * and it will be totally deleted later after all slaves are gone */
+static void libxl__sshm_del_master(libxl__gc *gc, xs_transaction_t xt,
+   uint32_t domid, const char *id)
+{
+char *sshm_path;
+
+sshm_path = libxl__xs_get_sshmpath(gc, id);
+
+/* we know that domid can't be both a master and a slave for one id
+ * (enforced in the *_add_master() and *_add_slave() code),
+ * so the number of slaves won't change during iteration. Simply check
+ * sshm_path/slaves to tell if there are still living slaves. */
+if (libxl__xs_read(gc, xt, GCSPRINTF("%s/slaves", sshm_path))) {
+SSHM_ERROR(domid, id,
+   "there are living slaves, won't be totally destroyed");
+
+libxl__xs_write_checked(gc, xt,
+GCSPRINTF("%s/status", sshm_path),
+"zombie");
+} else {
+libxl__xs_path_cleanup(gc, xt, sshm_path);
+}
+
+return;
+}
+
+static void libxl__sshm_do_unmap(libxl__gc *gc, uint32_t domid, const char *id,
+ uint64_t begin, uint64_t end)
+{
+begin >>= 12;
+end >>= 12;
+for (; begin < end; ++begin) {
+if (xc_domain_remove_from_physmap(CTX->xch, domid, begin)) {
+SSHM_ERROR(domid, id,
+   "unable to unmap shared page at 0x%"PRIx64".",
+   begin);
+}
+}
+}
+
+static void libxl__sshm_del_slave(libxl__gc *gc, xs_transaction_t xt,
+  uint32_t domid, const char *id, bool isretry)
+{
+char *sshm_path, *slave_path;
+char *master_stat, *mdomid_str, *begin_str, *end_str;
+uint64_t begin, end;
+uint32_t master_domid;
+
+sshm_path = libxl__xs_get_sshmpath(gc, id);
+slave_path = GCSPRINTF("%s/slaves/%"PRIu32, sshm_path, domid);
+
+begin_str = libxl__xs_read(gc, xt, GCSPRINTF("%s/begin", slave_path));
+end_str = libxl__xs_read(gc, xt, GCSPRINTF("%s/end", slave_path));
+begin = strtoull(begin_str, NULL, 16);
+end = strtoull(end_str, NULL, 16);
+
+/* Avoid calling do_unmap many times in case of xs transaction retry */
+if 

[Xen-devel] [PATCH 3/6] libxl:xl: add parsing code to parse "libxl_static_sshm" from xl config files

[Zhongze Liu]

Add the parsing utils for the newly introduced libxl_static_sshm struct
to the libxl/libxlu_* family. And add realated parsing code in xl to
parse the struct from xl config files. This is for the proposal "Allow
setting up shared memory areas between VMs from xl config file" (see [1]).

[1] https://lists.xenproject.org/archives/html/xen-devel/2017-07/msg03047.html

Signed-off-by: Zhongze Liu 

Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
Cc: Julien Grall 
Cc: xen-devel@lists.xen.org
---
 tools/libxl/Makefile  |   2 +-
 tools/libxl/libxlu_sshm.c | 210 ++
 tools/libxl/libxlutil.h   |   6 ++
 tools/xl/xl_parse.c   |  24 +-
 4 files changed, 240 insertions(+), 2 deletions(-)
 create mode 100644 tools/libxl/libxlu_sshm.c

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 082af8f716..3b63fb2cad 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -175,7 +175,7 @@ AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h _libxl_list.h 
_paths.h \
 AUTOSRCS= libxlu_cfg_y.c libxlu_cfg_l.c
 AUTOSRCS += _libxl_save_msgs_callout.c _libxl_save_msgs_helper.c
 LIBXLU_OBJS = libxlu_cfg_y.o libxlu_cfg_l.o libxlu_cfg.o \
-   libxlu_disk_l.o libxlu_disk.o libxlu_vif.o libxlu_pci.o
+   libxlu_disk_l.o libxlu_disk.o libxlu_vif.o libxlu_pci.o libxlu_sshm.o
 $(LIBXLU_OBJS): CFLAGS += $(CFLAGS_libxenctrl) # For xentoollog.h
 
 $(TEST_PROG_OBJS) _libxl.api-for-check: CFLAGS += $(CFLAGS_libxentoollog)
diff --git a/tools/libxl/libxlu_sshm.c b/tools/libxl/libxlu_sshm.c
new file mode 100644
index 00..8647665213
--- /dev/null
+++ b/tools/libxl/libxlu_sshm.c
@@ -0,0 +1,210 @@
+#include "libxl_osdeps.h" /* must come before any other headers */
+#include "libxlu_internal.h"
+
+#include 
+
+#define PARAM_RE(EXPR) "^\\s*" EXPR "\\s*(,|$)"
+#define WORD_RE "([_a-zA-Z0-9]+)"
+#define EQU_RE PARAM_RE(WORD_RE "\\s*=\\s*" WORD_RE)
+
+#define PAGE_SIZE_MASK ((uint64_t)0xfff)
+
+#define RET_INVAL(msg, curr_str)  do {  \
+xlu__sshm_err(cfg, msg, curr_str);  \
+rc = EINVAL;\
+goto out;   \
+} while(0)
+
+/* set a member in libxl_static_shm and report an error if it's respecified,
+ * @curr_str indicates the head of the remaining string. */
+#define SET_VAL(var, name, type, value, curr_str)  do { \
+if ((var) != LIBXL_SSHM_##type##_UNKNOWN && (var) != value) {   \
+RET_INVAL("\"" name "\" respecified", curr_str);\
+}   \
+(var) = value;  \
+} while(0)
+
+
+static void xlu__sshm_err(XLU_Config *cfg, const char *msg,
+  const char *curr_str) {
+fprintf(cfg->report,
+"%s: config parsing error in shared_memory: %s at '%s'\n",
+cfg->config_source, msg, curr_str);
+}
+
+static int parse_prot(XLU_Config *cfg, char *str, libxl_sshm_prot *prot)
+{
+int rc;
+libxl_sshm_prot new_prot;
+
+if (!strcmp(str, "rw")) {
+new_prot = LIBXL_SSHM_PROT_RW;
+} else {
+RET_INVAL("invalid permission flags", str);
+}
+
+SET_VAL(*prot, "permission flags", PROT, new_prot, str);
+
+rc = 0;
+
+ out:
+return rc;
+}
+
+static int parse_cachepolicy(XLU_Config *cfg, char *str,
+ libxl_sshm_cachepolicy *policy)
+{
+int rc;
+libxl_sshm_cachepolicy new_policy;
+
+if (!strcmp(str, "ARM_normal")) {
+new_policy = LIBXL_SSHM_CACHEPOLICY_ARM_NORMAL;
+} else if (!strcmp(str, "x86_normal")) {
+new_policy = LIBXL_SSHM_CACHEPOLICY_X86_NORMAL;
+} else {
+RET_INVAL("invalid cache policy", str);
+}
+
+SET_VAL(*policy, "cache policy", CACHEPOLICY, new_policy, str);
+rc = 0;
+
+ out:
+return rc;
+}
+
+/* handle key = value pairs */
+static int handle_equ(XLU_Config *cfg, char *key, char *val,
+  libxl_static_shm *sshm)
+{
+int rc;
+
+if (!strcmp(key, "id")) {
+if (strlen(val) > LIBXL_SSHM_ID_MAXLEN) { RET_INVAL("id too long", 
val); }
+if (sshm->id && !strcmp(sshm->id, val)) {
+RET_INVAL("id respecified", val);
+}
+
+if (NULL == (sshm->id = strdup(val))) {
+fprintf(stderr, "sshm parser out of memory\n");
+rc = ENOMEM;
+goto out;
+}
+} else if (!strcmp(key, "role")) {
+libxl_sshm_role new_role;
+
+if (!strcmp("master", val)) {
+new_role = LIBXL_SSHM_ROLE_MASTER;
+ 

[Xen-devel] [PATCH 4/6] xsm: flask: change the interface and default policy for xsm_map_gmfn_foregin

[Zhongze Liu]

The original xsm_map_gmfn_foregin policy checks if source domain has the proper
privileges over the target domain. Under this policy, it's not allowed if a Dom0
wants to map pages from one DomU to another, this restricts some useful yet not
dangerous usages of the API, such as sharing pages among DomU's by calling
XENMEM_add_to_physmap from Dom0.

Change the policy to: IIF current domain has the proper privilege on the
target domain and source domain, grant the access.

References to this xsm check have also been updated to pass the current
domain as a new parameter.

This is for the proposal "Allow setting up shared memory areas between VMs
from xl config file" (see [1]).

[1] https://lists.xenproject.org/archives/html/xen-devel/2017-07/msg03047.html

Signed-off-by: Zhongze Liu 

Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: George Dunlap 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Daniel De Graaf 
Cc: xen-devel@lists.xen.org
---
 xen/arch/arm/mm.c   | 2 +-
 xen/arch/x86/mm/p2m.c   | 2 +-
 xen/include/xsm/dummy.h | 6 --
 xen/include/xsm/xsm.h   | 7 ---
 xen/xsm/flask/hooks.c   | 6 --
 5 files changed, 14 insertions(+), 9 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index a810a056d7..9ec78d8c03 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -1284,7 +1284,7 @@ int xenmem_add_to_physmap_one(
 return -EINVAL;
 }
 
-rc = xsm_map_gmfn_foreign(XSM_TARGET, d, od);
+rc = xsm_map_gmfn_foreign(XSM_TARGET, current->domain, d, od);
 if ( rc )
 {
 rcu_unlock_domain(od);
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index e8a57d118c..a547fd00c0 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -2545,7 +2545,7 @@ int p2m_add_foreign(struct domain *tdom, unsigned long 
fgfn,
 if ( tdom == fdom )
 goto out;
 
-rc = xsm_map_gmfn_foreign(XSM_TARGET, tdom, fdom);
+rc = xsm_map_gmfn_foreign(XSM_TARGET, current->domain, tdom, fdom);
 if ( rc )
 goto out;
 
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 62fcea6f04..28dbc6f2a2 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -525,10 +525,12 @@ static XSM_INLINE int 
xsm_remove_from_physmap(XSM_DEFAULT_ARG struct domain *d1,
 return xsm_default_action(action, d1, d2);
 }
 
-static XSM_INLINE int xsm_map_gmfn_foreign(XSM_DEFAULT_ARG struct domain *d, 
struct domain *t)
+static XSM_INLINE int xsm_map_gmfn_foreign(XSM_DEFAULT_ARG struct domain *cd,
+   struct domain *d, struct domain *t)
 {
 XSM_ASSERT_ACTION(XSM_TARGET);
-return xsm_default_action(action, d, t);
+return xsm_default_action(action, cd, d) ||
+xsm_default_action(action, cd, t);
 }
 
 static XSM_INLINE int xsm_hvm_param(XSM_DEFAULT_ARG struct domain *d, unsigned 
long op)
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 60c0fd6a62..a20654a803 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -85,7 +85,7 @@ struct xsm_operations {
 int (*memory_pin_page) (struct domain *d1, struct domain *d2, struct 
page_info *page);
 int (*add_to_physmap) (struct domain *d1, struct domain *d2);
 int (*remove_from_physmap) (struct domain *d1, struct domain *d2);
-int (*map_gmfn_foreign) (struct domain *d, struct domain *t);
+int (*map_gmfn_foreign) (struct domain *cd, struct domain *d, struct 
domain *t);
 int (*claim_pages) (struct domain *d);
 
 int (*console_io) (struct domain *d, int cmd);
@@ -372,9 +372,10 @@ static inline int xsm_remove_from_physmap(xsm_default_t 
def, struct domain *d1,
 return xsm_ops->remove_from_physmap(d1, d2);
 }
 
-static inline int xsm_map_gmfn_foreign (xsm_default_t def, struct domain *d, 
struct domain *t)
+static inline int xsm_map_gmfn_foreign (xsm_default_t def, struct domain *cd,
+struct domain *d, struct domain *t)
 {
-return xsm_ops->map_gmfn_foreign(d, t);
+return xsm_ops->map_gmfn_foreign(cd, d, t);
 }
 
 static inline int xsm_claim_pages(xsm_default_t def, struct domain *d)
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 91146275bb..3408b6b9e1 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1165,9 +1165,11 @@ static int flask_remove_from_physmap(struct domain *d1, 
struct domain *d2)
 return domain_has_perm(d1, d2, SECCLASS_MMU, MMU__PHYSMAP);
 }
 
-static int flask_map_gmfn_foreign(struct domain *d, struct domain *t)
+static int flask_map_gmfn_foreign(struct domain *cd,
+  struct domain *d, struct domain *t)
 {
-return domain_has_perm(d, t, SECCLASS_MMU, MMU__MAP_READ | MMU__MAP_WRITE);
+return domain_has_perm(cd, d, SECCLASS_MMU, MMU__MAP_READ | 
MMU__MAP_WRITE) ||
+ 

[Xen-devel] [PATCH 2/6] libxl: introduce a new structure to represent static shared memory regions

[Zhongze Liu]

Add a new structure to the IDL famliy to represent static shared memory regions,
as proposed in the proposal "Allow setting up shared memory areas between VMs
from xl config file" (see [1]).

[1] https://lists.xenproject.org/archives/html/xen-devel/2017-07/msg03047.html

Signed-off-by: Zhongze Liu 

Cc: Wei Liu 
Cc: Ian Jackson 
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: xen-devel@lists.xen.org
---
 tools/libxl/libxl.h |  4 
 tools/libxl/libxl_types.idl | 36 
 2 files changed, 36 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 229e289750..3ee788642f 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -2237,6 +2237,10 @@ int libxl_fd_set_nonblock(libxl_ctx *ctx, int fd, int 
nonblock);
 int libxl_qemu_monitor_command(libxl_ctx *ctx, uint32_t domid,
const char *command_line, char **output);
 
+/* Constants for libxl_static_shm */
+#define LIBXL_SSHM_RANGE_UNKNOWN UINT64_MAX
+#define LIBXL_SSHM_ID_MAXLEN128
+
 #include 
 
 #endif /* LIBXL_H */
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 6e80d36256..6c9e79c05d 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -472,7 +472,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
 ("blkdev_start",string),
 
 ("vnuma_nodes", Array(libxl_vnode_info, "num_vnuma_nodes")),
-
+
 ("device_model_version", libxl_device_model_version),
 ("device_model_stubdomain", libxl_defbool),
 # if you set device_model you must set device_model_version too
@@ -494,7 +494,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
 ("ioports",  Array(libxl_ioport_range, "num_ioports")),
 ("irqs", Array(uint32, "num_irqs")),
 ("iomem",Array(libxl_iomem_range, "num_iomem")),
-("claim_mode",  libxl_defbool),
+("claim_mode",   libxl_defbool),
 ("event_channels",   uint32),
 ("kernel",   string),
 ("cmdline",  string),
@@ -543,10 +543,10 @@ libxl_domain_build_info = Struct("domain_build_info",[
("keymap",   string),
("sdl",  libxl_sdl_info),
("spice",libxl_spice_info),
-   
+
("gfx_passthru", libxl_defbool),
("gfx_passthru_kind", 
libxl_gfx_passthru_kind),
-   
+
("serial",   string),
("boot", string),
("usb",  libxl_defbool),
@@ -779,6 +779,33 @@ libxl_device_channel = Struct("device_channel", [
])),
 ])
 
+libxl_sshm_cachepolicy = Enumeration("sshm_cachepolicy", [
+(-1, "UNKNOWN"),
+(0,  "ARM_NORMAL"),  # ARM policies should be < 32
+(32,  "X86_NORMAL"), # X86 policies should be >= 32
+], init_val = "LIBXL_SSHM_CHCHE_POLICY_UNKNOWN")
+
+libxl_sshm_prot = Enumeration("sshm_prot", [
+(-1, "UNKNOWN"),
+(3,  "RW"),
+], init_val = "LIBXL_SSHM_PROT_UNKNOWN")
+
+libxl_sshm_role = Enumeration("sshm_role", [
+(-1, "UNKNOWN"),
+(0,  "MASTER"),
+(1,  "SLAVE"),
+], init_val = "LIBXL_SSHM_ROLE_UNKNOWN")
+
+libxl_static_shm = Struct("static_shm", [
+("id", string),
+("offset", uint64, {'init_val': 'LIBXL_SSHM_RANGE_UNKNOWN'}),
+("begin", uint64, {'init_val': 'LIBXL_SSHM_RANGE_UNKNOWN'}),
+("end", uint64, {'init_val': 'LIBXL_SSHM_RANGE_UNKNOWN'}),
+("prot", libxl_sshm_prot, {'init_val': 'LIBXL_SSHM_PROT_UNKNOWN'}),
+("cache_policy", libxl_sshm_cachepolicy, {'init_val': 
'LIBXL_SSHM_CACHEPOLICY_UNKNOWN'}),
+("role", libxl_sshm_role, {'init_val': 'LIBXL_SSHM_ROLE_UNKNOWN'}),
+])
+
 libxl_domain_config = Struct("domain_config", [
 ("c_info", libxl_domain_create_info),
 ("b_info", libxl_domain_build_info),
@@ -797,6 +824,7 @@ libxl_domain_config = Struct("domain_config", [
 ("channels", Array(libxl_device_channel, "num_channels")),
 ("usbctrls", Array(libxl_device_usbctrl, "num_usbctrls")),
 ("usbdevs", Array(libxl_device_usbdev, "num_usbdevs")),
+("sshms", Array(libxl_static_shm, "num_sshms")),
 
 ("on_poweroff", libxl_action_on_shutdown),
 ("on_reboot", libxl_action_on_shutdown),
-- 
2.14.0


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

[Xen-devel] [PATCH 1/6] libxc: add xc_domain_remove_from_physmap to wrap XENMEM_remove_from_physmap

[Zhongze Liu]

This is for the proposal "Allow setting up shared memory areas between VMs
from xl config file". See:

  https://lists.xenproject.org/archives/html/xen-devel/2017-07/msg03047.html

Then plan is to use XENMEM_add_to_physmap_batch to map the shared pages from
one domU to another and use XENMEM_remove_from_physmap to cancel the sharing.
A wrapper to XENMEM_add_to_physmap_batch was added in the following commit:

  commit 20e725e9364cff4a29945f66986ecd88cca8743d

Now add the wrapper to XENMEM_remove_from_physmap.

Signed-off-by: Zhongze Liu 
Reviewed-by: Stefano Stabellini 

Cc: Ian Jackson 
Cc: Wei Liu 
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: xen-devel@lists.xen.org
---
 tools/libxc/include/xenctrl.h |  4 
 tools/libxc/xc_domain.c   | 11 +++
 2 files changed, 15 insertions(+)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index c7710b8f36..0ff15a9255 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1381,6 +1381,10 @@ int xc_domain_add_to_physmap_batch(xc_interface *xch,
xen_pfn_t *gfpns,
int *errs);
 
+int xc_domain_remove_from_physmap(xc_interface *xch,
+  domid_t domid,
+  xen_pfn_t gpfn);
+
 int xc_domain_populate_physmap(xc_interface *xch,
uint32_t domid,
unsigned long nr_extents,
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index 3bab4e8bab..e6b32792c0 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -1077,6 +1077,17 @@ out:
 return rc;
 }
 
+int xc_domain_remove_from_physmap(xc_interface *xch,
+  domid_t domid,
+  xen_pfn_t gpfn)
+{
+struct xen_remove_from_physmap xrfp = {
+.domid = domid,
+.gpfn = gpfn,
+};
+return do_memory_op(xch, XENMEM_remove_from_physmap, , sizeof(xrfp));
+}
+
 int xc_domain_claim_pages(xc_interface *xch,
uint32_t domid,
unsigned long nr_pages)
-- 
2.14.0


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

[Xen-devel] [PATCH 0/6] Allow setting up shared memory areas between VMs from xl config files

[Zhongze Liu]

This series implements the new xl config entry proposed in [1]. Users can use
the new config entry to statically setup shared memory areas among VMs so that
they could communicate with each other through the static shared memory areas.

[1] Proposla to allow setting up shared memory areas between VMs from xl config 
file:
https://lists.xenproject.org/archives/html/xen-devel/2017-07/msg03047.html

Cheers,

Zhongze Liu (6):
  libxc: add xc_domain_remove_from_physmap to wrap
XENMEM_remove_from_physmap
  libxl: introduce a new structure to represent static shared memory
regions
  libxl:xl: add parsing code to parse "libxl_static_sshm" from xl config
files
  xsm: flask: change the interface and default policy for
xsm_map_gmfn_foregin
  libxl: support mapping static shared memory areas during domain
creation
  libxl: support unmapping static shared memory areas during domain
destruction

 tools/libxc/include/xenctrl.h |   4 +
 tools/libxc/xc_domain.c   |  11 +
 tools/libxl/Makefile  |   4 +-
 tools/libxl/libxl.h   |   4 +
 tools/libxl/libxl_arch.h  |   6 +
 tools/libxl/libxl_arm.c   |  15 ++
 tools/libxl/libxl_create.c|  27 +++
 tools/libxl/libxl_domain.c|   5 +
 tools/libxl/libxl_internal.h  |  16 ++
 tools/libxl/libxl_sshm.c  | 461 ++
 tools/libxl/libxl_types.idl   |  36 +++-
 tools/libxl/libxl_x86.c   |  18 ++
 tools/libxl/libxl_xshelp.c|   8 +
 tools/libxl/libxlu_sshm.c | 210 +++
 tools/libxl/libxlutil.h   |   6 +
 tools/xl/xl_parse.c   |  24 ++-
 xen/arch/arm/mm.c |   2 +-
 xen/arch/x86/mm/p2m.c |   2 +-
 xen/include/xsm/dummy.h   |   6 +-
 xen/include/xsm/xsm.h |   7 +-
 xen/xsm/flask/hooks.c |   6 +-
 21 files changed, 862 insertions(+), 16 deletions(-)
 create mode 100644 tools/libxl/libxl_sshm.c
 create mode 100644 tools/libxl/libxlu_sshm.c

-- 
2.14.0


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

Re: [Xen-devel] [PATCH] xen: Emit RTC_CHANGE upon TIMEOFFSET ioreq

[Stefano Stabellini]

On Tue, 22 Aug 2017, Ross Lagerwall wrote:
> On 08/21/2017 11:30 PM, Stefano Stabellini wrote:
> > On Mon, 21 Aug 2017, Ross Lagerwall wrote:
> > > When the guest writes to the RTC, Xen emulates it and broadcasts a
> > > TIMEOFFSET ioreq. Emit an RTC_CHANGE QMP message when this happens
> > > rather than ignoring it so that something useful can be done with the
> > > information.
> > 
> > Are there any handlers of the RTC_CHANGE QMP message today? What happens
> > if there are no handlers?
> 
> The libxl toolstack doesn't handle it nor does the XAPI project currently,
> although we plan on modifying XAPI to handle it.
> 
> It is simply an event that is broadcast to any QMP monitors. If nothing
> handles the event, then it is the same behavior as before. If something is
> interested in the event, then it can make use of the time offset however it
> wants.

OK, please expland the patch description and repost.

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

Re: [Xen-devel] [PATCH 04/27] xen/mm: Move {G, M]FN <-> {G, M}ADDR helpers to common code

[Julien Grall]

Hi Jan,

On 22/08/17 09:23, Jan Beulich wrote:

On 14.08.17 at 16:23,  wrote:

--- a/xen/include/xen/mm.h
+++ b/xen/include/xen/mm.h
@@ -92,6 +92,9 @@ static inline bool_t mfn_eq(mfn_t x, mfn_t y)
 return mfn_x(x) == mfn_x(y);
 }

+#define maddr_to_mfn(maddr) _mfn(paddr_to_pfn(maddr))
+#define mfn_to_maddr(mfn)   pfn_to_paddr(mfn_x(mfn))
+
 TYPE_SAFE(unsigned long, gfn);
 #define PRI_gfn  "05lx"
 #define INVALID_GFN  _gfn(~0UL)
@@ -130,6 +133,9 @@ static inline bool_t gfn_eq(gfn_t x, gfn_t y)
 return gfn_x(x) == gfn_x(y);
 }

+#define gaddr_to_gfn(gaddr) _gfn(paddr_to_pfn(gaddr))
+#define gfn_to_gaddr(gfn)   pfn_to_paddr(gfn_x(gfn))
+
 TYPE_SAFE(unsigned long, pfn);
 #define PRI_pfn  "05lx"
 #define INVALID_PFN  (~0UL)


Hmm, if you want this in common code, I think this needs to be
correct from a more abstract perspective, i.e. not just for ARM
and x86. In general I don't think we can assume machine,
physical, and guest addresses to all be the same width (which
the uses above imply). IOW I think these would better stay
arch-specific, and if you want to use them in common code
you'll need to add x86 variants.


I will do that.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 03/27] xen/x86: mm: Don't check alloc_boot_pages return

[Julien Grall]

On 22/08/17 12:28, Andre Przywara wrote:

Hi,


Hi Andre,



On 14/08/17 15:23, Julien Grall wrote:

The only way alloc_boot_pages will return 0 is during the error case.


This statement is not true. If alloc_boot_pages() returns, it has
succeeded. Returning 0 is nothing special.


Although, Xen will panic in the error path. So the check in the caller
is pointless.

Looking at the loop, my understanding is it will try to allocate in
smaller chunk if a bigger chunk fail. Given that alloc_boot_pages can
never check, the loop seems unecessary.


Agreed, the algorithm doesn't work with (current) implementation of
alloc_boot_pages(), so the patch is valid.


Signed-off-by: Julien Grall 


Given that you adjust the commit message:

Reviewed-by: Andre Przywara 


The first 3 patches were already committed a few days ago, so we would 
have to stick with the current message.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 5/5] ARM: ITS: Pass ITS in Hardware Domain MADT

[Julien Grall]

Hello,

Title: xen/arm: ITS: Expose ITS in the MADT table

On 13/08/17 22:30, mja...@caviumnetworks.com wrote:

From: Manish Jaggi 

Adds gicv3_its_make_hwdom_madt to update hwdom MADT ITS information.


s/Adds/Add/



Signed-off-by: Manish Jaggi 
---
 xen/arch/arm/gic-v3-its.c| 24 
 xen/arch/arm/gic-v3.c|  1 +
 xen/include/asm-arm/gic_v3_its.h |  1 +
 3 files changed, 26 insertions(+)

diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index 82e025e..6e0a701 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -935,6 +935,30 @@ u32 gicv3_its_madt_generic_translator_size(void)

 return size;
 }
+
+u32 gicv3_its_make_hwdom_madt(u8 *base_ptr, u32 offset)


Pretty much all my remarks in the previous patch for u* are valid here 
too. I will not repeat them and for the whole the patch.



+{
+const struct host_its *its_data;
+u32 table_len = offset, i = 0, size;
+struct acpi_madt_generic_translator *fw_its;
+struct acpi_madt_generic_translator *hwdom_its;
+
+size = sizeof(struct acpi_madt_generic_translator);
+
+/* Update GIC ITS information in hardware domain's MADT */
+list_for_each_entry(its_data, _its_list, entry)


Please look at vgic_v3_its_count to avoid introduce dummy variables:

for ( i = 0; i < vgic_v3_its_count(...); i++ )


+{
+hwdom_its = (struct acpi_madt_generic_translator *)(base_ptr
+   + table_len);
+fw_its = (struct acpi_madt_generic_translator *)
+acpi_table_get_entry_madt(
+ACPI_MADT_TYPE_GENERIC_TRANSLATOR, i++);


Please check the return here + panic if it does not work.


+memcpy(hwdom_its, fw_its, size);
+table_len +=  size;


This code is too complicate for not much reason. If you do:

hwdom_its = (struct acpi_madt_generic_translator)(base_ptr + offset);

for ( i = 0; i < vgic_v3_its_count(...); i++ )
{
fw_its = (struct  *)acpi_table_get_...

hwdom_its++;
}

return (offset + sizeof(...) * vgic_v3_its_count());

That would be much clear.


+}
+
+return table_len;
+}
 #endif
 /*
  * Create the respective guest DT nodes from a list of host ITSes.
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 6c2b562..30b29c9 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -1407,6 +1407,7 @@ static int gicv3_make_hwdom_madt(const struct domain *d, 
u32 offset)
 table_len += size;
 }

+table_len = gicv3_its_make_hwdom_madt(base_ptr, table_len);


Newline here.


 return table_len;
 }

diff --git a/xen/include/asm-arm/gic_v3_its.h b/xen/include/asm-arm/gic_v3_its.h
index b849b16..8955451 100644
--- a/xen/include/asm-arm/gic_v3_its.h
+++ b/xen/include/asm-arm/gic_v3_its.h
@@ -139,6 +139,7 @@ void gicv3_its_dt_init(const struct dt_device_node *node);
 int gicv3_its_acpi_init(struct acpi_subtable_header *header,
 const unsigned long end);
 u32 gicv3_its_madt_generic_translator_size(void);
+u32 gicv3_its_make_hwdom_madt(u8 *base_ptr, u32 offset);
 #endif
 /* Deny iomem access for its */
 int gicv3_its_deny_access(const struct domain *d);



Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 22/27] xen/arm: Switch to SYS_STATE_boot just after end_boot_allocator()

[Andre Przywara]

Hi,

On 14/08/17 15:24, Julien Grall wrote:
> We should consider the early boot period to end when we stop using the
> boot allocator. This is inline with x86 and will be helpful to know
> whether we should allocate memory from the boot allocator or xenheap.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Andre Przywara 

Cheers,
Andre.

> ---
>  xen/arch/arm/setup.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index 277b566b88..46737a2eca 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -757,6 +757,12 @@ void __init start_xen(unsigned long boot_phys_offset,
>  
>  end_boot_allocator();
>  
> +/*
> + * The memory subsystem has been initialized, we can now switch from
> + * early_boot -> boot.
> + */
> +system_state = SYS_STATE_boot;
> +
>  vm_init();
>  
>  if ( acpi_disabled )
> @@ -779,8 +785,6 @@ void __init start_xen(unsigned long boot_phys_offset,
>  console_init_preirq();
>  console_init_ring();
>  
> -system_state = SYS_STATE_boot;
> -
>  processor_id();
>  
>  smp_init_cpus();
> 

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

Re: [Xen-devel] [PATCH 17/27] xen/arm: page: Use directly BUFFERABLE and drop DEV_WC

[Andre Przywara]

Hi,

On 14/08/17 15:24, Julien Grall wrote:
> DEV_WC is only used for PAGE_HYPERVISOR_WC and does not bring much
> improvement.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Andre Przywara 

Cheers,
Andre.

> ---
>  xen/include/asm-arm/page.h | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
> index 465300c6e5..660e1779c5 100644
> --- a/xen/include/asm-arm/page.h
> +++ b/xen/include/asm-arm/page.h
> @@ -55,11 +55,10 @@
>  #define WRITEBACK 0x3
>  #define DEV_SHARED0x4
>  #define WRITEALLOC0x7
> -#define DEV_WCBUFFERABLE
>  
>  #define PAGE_HYPERVISOR (WRITEALLOC)
>  #define PAGE_HYPERVISOR_NOCACHE (DEV_SHARED)
> -#define PAGE_HYPERVISOR_WC  (DEV_WC)
> +#define PAGE_HYPERVISOR_WC  (BUFFERABLE)
>  
>  /*
>   * Defines for changing the hypervisor PTE .ro and .nx bits. This is only to 
> be
> 

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

Re: [Xen-devel] [PATCH 15/27] xen/arm: Replace ioremap_attr(PAGE_HYPERVISOR_NOCACHE) call by ioremap_nocache

[Andre Przywara]

Hi,

On 14/08/17 15:24, Julien Grall wrote:
> ioremap_cache is a wrapper of ioremap_attr(...).
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Andre Przywara 

Cheers,
Andre

> ---
>  xen/arch/arm/platforms/exynos5.c | 2 +-
>  xen/arch/arm/platforms/omap5.c   | 6 ++
>  2 files changed, 3 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/arch/arm/platforms/exynos5.c 
> b/xen/arch/arm/platforms/exynos5.c
> index 2ae5fa66e0..95d6581d33 100644
> --- a/xen/arch/arm/platforms/exynos5.c
> +++ b/xen/arch/arm/platforms/exynos5.c
> @@ -62,7 +62,7 @@ static int exynos5_init_time(void)
>  dprintk(XENLOG_INFO, "mct_base_addr: %016llx size: %016llx\n",
>  mct_base_addr, size);
>  
> -mct = ioremap_attr(mct_base_addr, size, PAGE_HYPERVISOR_NOCACHE);
> +mct = ioremap_nocache(mct_base_addr, size);
>  if ( !mct )
>  {
>  dprintk(XENLOG_ERR, "Unable to map MCT\n");
> diff --git a/xen/arch/arm/platforms/omap5.c b/xen/arch/arm/platforms/omap5.c
> index 1e1f9fa970..7dbba95756 100644
> --- a/xen/arch/arm/platforms/omap5.c
> +++ b/xen/arch/arm/platforms/omap5.c
> @@ -51,8 +51,7 @@ static int omap5_init_time(void)
>  unsigned int sys_clksel;
>  unsigned int num, den, frac1, frac2;
>  
> -ckgen_prm_base = ioremap_attr(OMAP5_CKGEN_PRM_BASE,
> -  0x20, PAGE_HYPERVISOR_NOCACHE);
> +ckgen_prm_base = ioremap_nocache(OMAP5_CKGEN_PRM_BASE, 0x20);
>  if ( !ckgen_prm_base )
>  {
>  dprintk(XENLOG_ERR, "%s: PRM_BASE ioremap failed\n", __func__);
> @@ -64,8 +63,7 @@ static int omap5_init_time(void)
>  
>  iounmap(ckgen_prm_base);
>  
> -rt_ct_base = ioremap_attr(REALTIME_COUNTER_BASE,
> -  0x20, PAGE_HYPERVISOR_NOCACHE);
> +rt_ct_base = ioremap_nocache(REALTIME_COUNTER_BASE, 0x20);
>  if ( !rt_ct_base )
>  {
>  dprintk(XENLOG_ERR, "%s: REALTIME_COUNTER_BASE ioremap failed\n", 
> __func__);
> 

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

Re: [Xen-devel] [PATCH 14/27] xen/arm: traps: Improve logging for data/prefetch abort fault

[Andre Przywara]

Hi,

On 14/08/17 15:24, Julien Grall wrote:
> Walk the hypervisor page table for data/prefetch abort fault to help
> diagnostics error in the page tables.
> 
> Signed-off-by: Julien Grall 
> ---
>  xen/arch/arm/traps.c | 19 +++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index 819bdbc69e..dac4e54fa7 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -2967,7 +2967,26 @@ asmlinkage void do_trap_hyp_sync(struct cpu_user_regs 
> *regs)
>  do_trap_brk(regs, hsr);
>  break;
>  #endif
> +case HSR_EC_DATA_ABORT_CURR_EL:
> +case HSR_EC_INSTR_ABORT_CURR_EL:
> +{
> +bool is_data = (hsr.ec == HSR_EC_DATA_ABORT_CURR_EL);
> +const char *fault = (is_data) ? "Data Abort" : "Instruction Abort";
> +
> +printk("%s Trap. Syndrome=%#x\n", fault, hsr.iss);
> +/*
> + * FAR may not be valid for a Synchronous External abort other
> + * than translation table walk.
> + */
> +if ( hsr.xabt.fsc != FSC_SEA || !hsr.xabt.fnv )

This is quite hard to read. Would the DeMorgan'ed version be better?
   if ( hsr.xabt.fsc == FSC_SEA && hsr.xabt.fnv )
   printk 
   else
   dump_hyp_walk ...

> +dump_hyp_walk(get_hfar(is_data));
> +else
> +printk("Invalid FAR, don't walk the hypervisor tables\n");

Nit: "not walking" sounds less ambiguous.

> +do_unexpected_trap(fault, regs);
>  
> +break;
> +}
>  default:
>  printk("Hypervisor Trap. HSR=0x%x EC=0x%x IL=%x 
> Syndrome=0x%"PRIx32"\n",
> hsr.bits, hsr.ec, hsr.len, hsr.iss);

Ignoring the nits above:
Reviewed-by: Andre Przywara 

Cheers,
Andre.

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

Re: [Xen-devel] [PATCH 13/27] xen/arm: traps: Introduce a helper to read the hypersivor fault register

[Andre Przywara]

Hi,

On 14/08/17 15:24, Julien Grall wrote:
> While ARM32 has 2 distinct registers for the hypervisor fault register
> (one for prefetch abort, the other for data abort), AArch64 has only
> one.
> 
> Currently, the logic is open-code but a follow-up patch will require to
> read it too. So move the logic in a separate helper and use it instead
> of open-coding it.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Andre Przywara 

Cheers,
Andre.

> ---
>  xen/arch/arm/traps.c | 35 +--
>  1 file changed, 25 insertions(+), 10 deletions(-)
> 
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index 498d8c594a..819bdbc69e 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -2530,6 +2530,28 @@ done:
>  if (first) unmap_domain_page(first);
>  }
>  
> +/*
> + * Return the value of the hypervisor fault address register.
> + *
> + * On ARM32, the register will be different depending whether the
> + * fault is a prefetch abort or data abort.
> + */
> +static inline vaddr_t get_hfar(bool is_data)
> +{
> +vaddr_t gva;
> +
> +#ifdef CONFIG_ARM_32
> +if ( is_data )
> +gva = READ_CP32(HDFAR);
> +else
> +gva = READ_CP32(HIFAR);
> +#else
> +gva =  READ_SYSREG(FAR_EL2);
> +#endif
> +
> +return gva;
> +}
> +
>  static inline paddr_t get_faulting_ipa(vaddr_t gva)
>  {
>  register_t hpfar = READ_SYSREG(HPFAR_EL2);
> @@ -2565,11 +2587,7 @@ static void do_trap_instr_abort_guest(struct 
> cpu_user_regs *regs,
>  paddr_t gpa;
>  mfn_t mfn;
>  
> -#ifdef CONFIG_ARM_32
> -gva = READ_CP32(HIFAR);
> -#else
> -gva = READ_SYSREG64(FAR_EL2);
> -#endif
> +gva = get_hfar(false /* is_data */);
>  
>  /*
>   * If this bit has been set, it means that this instruction abort is 
> caused
> @@ -2711,11 +2729,8 @@ static void do_trap_data_abort_guest(struct 
> cpu_user_regs *regs,
>  return __do_trap_serror(regs, true);
>  
>  info.dabt = dabt;
> -#ifdef CONFIG_ARM_32
> -info.gva = READ_CP32(HDFAR);
> -#else
> -info.gva = READ_SYSREG64(FAR_EL2);
> -#endif
> +
> +info.gva = get_hfar(true /* is_data */);
>  
>  if ( hpfar_is_valid(dabt.s1ptw, fsc) )
>  info.gpa = get_faulting_ipa(info.gva);
> 

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

Re: [Xen-devel] [PATCH 4/5] ARM: Introduce get_hwdom_madt_size in gic_hw_operations

[Julien Grall]

Hello,

On 13/08/17 22:30, mja...@caviumnetworks.com wrote:

From: Manish Jaggi 

estimate_acpi_efi_size needs to be updated to provide correct size of
hardware domains MADT, which now adds ITS information as well.

Introducing gic_get_hwdom_madt_size.

Signed-off-by: Manish Jaggi 
---
 xen/arch/arm/domain_build.c  |  7 +--
 xen/arch/arm/gic-v2.c|  6 ++
 xen/arch/arm/gic-v3-its.c| 12 
 xen/arch/arm/gic-v3.c| 17 +
 xen/arch/arm/gic.c   | 11 +++
 xen/include/asm-arm/gic.h|  3 +++
 xen/include/asm-arm/gic_v3_its.h |  6 ++
 7 files changed, 56 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 1bec4fa..5739ea4 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1806,12 +1806,7 @@ static int estimate_acpi_efi_size(struct domain *d, 
struct kernel_info *kinfo)
 acpi_size = ROUNDUP(sizeof(struct acpi_table_fadt), 8);
 acpi_size += ROUNDUP(sizeof(struct acpi_table_stao), 8);

-madt_size = sizeof(struct acpi_table_madt)
-+ sizeof(struct acpi_madt_generic_interrupt) * d->max_vcpus
-+ sizeof(struct acpi_madt_generic_distributor);
-if ( d->arch.vgic.version == GIC_V3 )
-madt_size += sizeof(struct acpi_madt_generic_redistributor)
- * d->arch.vgic.nr_regions;
+madt_size = gic_get_hwdom_madt_size(d);
 acpi_size += ROUNDUP(madt_size, 8);

 addr = acpi_os_get_root_pointer();
diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index cbe71a9..f5ca227 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -1012,6 +1012,11 @@ static int gicv2_iomem_deny_access(const struct domain 
*d)
 return iomem_deny_access(d, mfn, mfn + nr);
 }

+static u32 gicv2_get_hwdom_madt_size(const struct domain *d)


Please no more use of u32, use uint32_t. But, the return is a bit weird. 
Why 32-bit when the code is using size_t.


I think this should return unsigned long given you use them in 
combination with _xmalloc.



+{
+return 0;
+}
+
 #ifdef CONFIG_ACPI
 static int gicv2_make_hwdom_madt(const struct domain *d, u32 offset)
 {
@@ -1248,6 +1253,7 @@ const static struct gic_hw_operations gicv2_ops = {
 .read_apr= gicv2_read_apr,
 .make_hwdom_dt_node  = gicv2_make_hwdom_dt_node,
 .make_hwdom_madt = gicv2_make_hwdom_madt,
+.get_hwdom_madt_size = gicv2_get_hwdom_madt_size,
 .map_hwdom_extra_mappings = gicv2_map_hwdown_extra_mappings,
 .iomem_deny_access   = gicv2_iomem_deny_access,
 .do_LPI  = gicv2_do_LPI,
diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index f584d33..82e025e 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -924,6 +924,18 @@ int gicv3_its_deny_access(const struct domain *d)
 return rc;
 }

+#ifdef CONFIG_ACPI
+u32 gicv3_its_madt_generic_translator_size(void)


See my comment above.


+{
+const struct host_its *its_data;
+u32 size = 0;


Same here.


+
+list_for_each_entry(its_data, _its_list, entry)
+size += sizeof(struct acpi_madt_generic_translator);
+
+return size;
+}


Overall, I don't think this function is necessary. Instead you should 
use vgic_v3_its_count given that the ACPI table will for the hardware 
domain.



+#endif
 /*
  * Create the respective guest DT nodes from a list of host ITSes.
  * This copies the reg property, so the guest sees the ITS at the same address
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 045d20d..6c2b562 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -1410,6 +1410,17 @@ static int gicv3_make_hwdom_madt(const struct domain *d, 
u32 offset)
 return table_len;
 }

+static u32 gicv3_get_hwdom_madt_size(const struct domain *d)


Ditto


+{
+u32 size;


Ditto + newline here.


+size  = sizeof(struct acpi_madt_generic_redistributor)
+ * d->arch.vgic.nr_regions;
+if ( gicv3_its_host_has_its() )
+size  += gicv3_its_madt_generic_translator_size();


size += vgic_v3_its_count(d);


+
+return size;
+}
+
 static int __init
 gic_acpi_parse_madt_cpu(struct acpi_subtable_header *header,
 const unsigned long end)
@@ -1607,6 +1618,11 @@ static int gicv3_make_hwdom_madt(const struct domain *d, 
u32 offset)
 {
 return 0;
 }
+
+static u32 gicv3_get_hwdom_madt_size(const struct domain *d)
+{
+return 0;
+}
 #endif

 /* Set up the GIC */
@@ -1708,6 +1724,7 @@ static const struct gic_hw_operations gicv3_ops = {
 .secondary_init  = gicv3_secondary_cpu_init,
 .make_hwdom_dt_node  = gicv3_make_hwdom_dt_node,
 .make_hwdom_madt = gicv3_make_hwdom_madt,
+.get_hwdom_madt_size = gicv3_get_hwdom_madt_size,
 .iomem_deny_access   = gicv3_iomem_deny_access,
 .do_LPI  = gicv3_do_LPI,
 };
diff --git 

Re: [Xen-devel] [PATCH 1/5] ARM: ITS: Introduce common function add_to_host_its_list

[Julien Grall]

On 13/08/17 22:30, mja...@caviumnetworks.com wrote:

From: Manish Jaggi 

add_to_host_its_list will update the host_its_list. This common function to
be invoked from gicv3_its_dt_init and gic_v3_its_acpi_init.

Signed-off-by: Manish Jaggi 
---
 xen/arch/arm/gic-v3-its.c | 36 +++-
 1 file changed, 23 insertions(+), 13 deletions(-)

diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index 2d36030..f844a0d 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -976,12 +976,31 @@ int gicv3_its_make_hwdom_dt_nodes(const struct domain *d,
 return res;
 }

+/* Common function for adding to host_its_list */
+static int add_to_host_its_list(u64 addr, u64 size, const void *node)


BTW this should be paddr_t and not u64 for both.


+{
+struct host_its *its_data;
+its_data = xzalloc(struct host_its);
+
+if ( !its_data )
+return -1;
+
+its_data->addr = addr;
+its_data->size = size;
+if ( node )
+its_data->dt_node = node;
+
+printk("GICv3: Found ITS @0x%lx\n", addr);
+
+list_add_tail(_data->entry, _its_list);
+
+return 0;
+}
+
 /* Scan the DT for any ITS nodes and create a list of host ITSes out of it. */
 void gicv3_its_dt_init(const struct dt_device_node *node)
 {
 const struct dt_device_node *its = NULL;
-struct host_its *its_data;
-
 /*
  * Check for ITS MSI subnodes. If any, add the ITS register
  * frames to the ITS list.
@@ -996,17 +1015,8 @@ void gicv3_its_dt_init(const struct dt_device_node *node)
 if ( dt_device_get_address(its, 0, , ) )
 panic("GICv3: Cannot find a valid ITS frame address");

-its_data = xzalloc(struct host_its);
-if ( !its_data )
-panic("GICv3: Cannot allocate memory for ITS frame");
-
-its_data->addr = addr;
-its_data->size = size;
-its_data->dt_node = its;
-
-printk("GICv3: Found ITS @0x%lx\n", addr);
-
-list_add_tail(_data->entry, _its_list);
+if ( add_to_host_its_list(addr, size, its) )
+panic("GICV3: Adding Host ITS failed ");
 }
 }




--
Julien Grall

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

Re: [Xen-devel] [PATCH 3/5] ARM: ITS: Deny hardware domain access to its

[Julien Grall]

Hello,

On 13/08/17 22:30, mja...@caviumnetworks.com wrote:

From: Manish Jaggi 

This patch extends the gicv3_iomem_deny_access functionality by adding support
for its region as well. Added function gicv3_its_deny_access.


s/its/ITS/ making clearer the commit message.

s/Added/Add/



Signed-off-by: Manish Jaggi 
---
 xen/arch/arm/gic-v3-its.c| 19 +++
 xen/arch/arm/gic-v3.c|  7 +++
 xen/include/asm-arm/gic_v3_its.h |  8 
 3 files changed, 34 insertions(+)

diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index c4f1288..f584d33 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -20,6 +20,7 @@

 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -905,6 +906,24 @@ struct pending_irq *gicv3_assign_guest_event(struct domain 
*d,
 return pirq;
 }

+int gicv3_its_deny_access(const struct domain *d)
+{
+int rc = 0;
+unsigned long mfn, nr;
+const struct host_its *its_data;
+
+list_for_each_entry(its_data, _its_list, entry)
+{
+mfn = paddr_to_pfn(its_data->addr);
+nr = PFN_UP(ACPI_GICV3_ITS_MEM_SIZE);
+rc = iomem_deny_access(d, mfn, mfn + nr);
+if ( rc )
+break;
+}
+
+return rc;
+}
+
 /*
  * Create the respective guest DT nodes from a list of host ITSes.
  * This copies the reg property, so the guest sees the ITS at the same address
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 0be8942..045d20d 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -1308,6 +1308,13 @@ static int gicv3_iomem_deny_access(const struct domain 
*d)
 if ( rc )
 return rc;

+if ( gicv3_its_host_has_its() )


gicv3_its_deny_access will do nothing and return 0 when there are no ITS 
present. Same when Xen does not support ITS. So please drop this 
pointless check.



+{
+rc = gicv3_its_deny_access(d);
+if ( rc )
+return rc;
+}
+
 for ( i = 0; i < gicv3.rdist_count; i++ )
 {
 mfn = gicv3.rdist_regions[i].base >> PAGE_SHIFT;
diff --git a/xen/include/asm-arm/gic_v3_its.h b/xen/include/asm-arm/gic_v3_its.h
index b9d8957..a673fba 100644
--- a/xen/include/asm-arm/gic_v3_its.h
+++ b/xen/include/asm-arm/gic_v3_its.h
@@ -139,6 +139,9 @@ void gicv3_its_dt_init(const struct dt_device_node *node);
 int gicv3_its_acpi_init(struct acpi_subtable_header *header,
 const unsigned long end);
 #endif


Newline here please.


+/* Deny iomem access for its */
+int gicv3_its_deny_access(const struct domain *d);
+
 bool gicv3_its_host_has_its(void);

 unsigned int vgic_v3_its_count(const struct domain *d);
@@ -208,6 +211,11 @@ static inline int gicv3_its_acpi_init(struct 
acpi_subtable_header *header,
 }
 #endif

+static inline int gicv3_its_deny_access(const struct domain *d)
+{
+return 0;
+}
+
 static inline bool gicv3_its_host_has_its(void)
 {
 return false;



Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 2/5] ARM: ITS: Populate host_its_list from ACPI MADT Table

[Julien Grall]

Hello,

On 13/08/17 22:30, mja...@caviumnetworks.com wrote:

From: Manish Jaggi 

Added gicv3_its_acpi_init to update host_its_list from MADT table.
For ACPI, host_its sturcture  stores dt_node as NULL.


s/sturcture/structure/



Future TOD0:
Cleanup :(1) Remove from host_its dt_node as it is required only for ACPI
Enhancement :(2) Provide a method to access translation_id and
other fields of madt generic translator.


I don't get those TODOs. This is not related to this patch and does not 
really hence the commit message.




Signed-off-by: Manish Jaggi 
---
 xen/arch/arm/gic-v3-its.c| 14 ++
 xen/arch/arm/gic-v3.c|  8 
 xen/include/asm-arm/gic_v3_its.h | 13 +
 3 files changed, 35 insertions(+)

diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index f844a0d..c4f1288 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -32,6 +32,7 @@
 #include 

 #define ITS_CMD_QUEUE_SZSZ_1M
+#define ACPI_GICV3_ITS_MEM_SIZE(SZ_64K)


The (...) are not necessary.



 /*
  * No lock here, as this list gets only populated upon boot while scanning
@@ -1020,6 +1021,19 @@ void gicv3_its_dt_init(const struct dt_device_node *node)
 }
 }

+#ifdef CONFIG_ACPI
+int gicv3_its_acpi_init(struct acpi_subtable_header *header,
+const unsigned long end)


I don't much like the idea of providing a callback that will be called 
by gic-v3.c. I would much prefer to follow the same pattern as the DT 
where gic-v3.c will call a function in the gic-v3-its.c that will 
iterate on all possible ITS.


This will make a more sane interface.

Also, it would make sense to call it gicv3_its_acpi_probe.


+{
+struct acpi_madt_generic_translator *its;
+
+its = (struct acpi_madt_generic_translator *)header;



You probably want to add check BAD_MADT_ENTRY(its, end).


+
+return add_to_host_its_list(its->base_address,
+ACPI_GICV3_ITS_MEM_SIZE, NULL);


If you follow my suggestion in patch #1 regarding the return of 
add_to_host_its_list, then you would need to check true/false and return 
a correct errno.


Even if you don't follow it, please return an appropriate errno rather 
than -1.



+}
+#endif
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index f990eae..0be8942 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -1567,6 +1567,14 @@ static void __init gicv3_acpi_init(void)

 gicv3.rdist_stride = 0;

+/* Parse ITS information */
+count = acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_TRANSLATOR,
+  gicv3_its_acpi_init, 0);


See my comment above.


+
+if ( count <= 0 )


Hardware without ITS support will return 0 and therefore panic. You 
don't want this to happen.



+panic("GICv3: Can't get ITS entry");
+
+
 /*
  * In ACPI, 0 is considered as the invalid address. However the rest
  * of the initialization rely on the invalid address to be
diff --git a/xen/include/asm-arm/gic_v3_its.h b/xen/include/asm-arm/gic_v3_its.h
index 1fac1c7..2b7493d 100644
--- a/xen/include/asm-arm/gic_v3_its.h
+++ b/xen/include/asm-arm/gic_v3_its.h
@@ -105,6 +105,7 @@

 #include 
 #include 
+#include 


With the suggestion suggested above, you will not need to include 
 in gic_v3_its.h.




 #define HOST_ITS_FLUSH_CMD_QUEUE(1U << 0)
 #define HOST_ITS_USES_PTA   (1U << 1)
@@ -135,6 +136,10 @@ extern struct list_head host_its_list;
 /* Parse the host DT and pick up all host ITSes. */
 void gicv3_its_dt_init(const struct dt_device_node *node);

+#ifdef CONFIG_ACPI
+int gicv3_its_acpi_init(struct acpi_subtable_header *header,
+const unsigned long end);
+#endif


Newline here please.


 bool gicv3_its_host_has_its(void);

 unsigned int vgic_v3_its_count(const struct domain *d);
@@ -196,6 +201,14 @@ static inline void gicv3_its_dt_init(const struct 
dt_device_node *node)
 {
 }

+#ifdef CONFIG_ACPI
+static inline int gicv3_its_acpi_init(struct acpi_subtable_header *header,
+const unsigned long end)
+{
+return false;


gicv3_its_acpi_init return an int not a bool. Please modify this 
accordingly.



+}
+#endif
+
 static inline bool gicv3_its_host_has_its(void)
 {
 return false;



Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH V2 8/25] tools/libxl: Add a user configurable parameter to control vIOMMU attributes

[Roger Pau Monné]

On Wed, Aug 09, 2017 at 04:34:09PM -0400, Lan Tianyu wrote:
> From: Chao Gao 
> 
> A field, viommu_info, is added to struct libxl_domain_build_info. Several
> attributes can be specified by guest config file for virtual IOMMU. These
> attributes are used for DMAR construction and vIOMMU creation.
> 
> Signed-off-by: Chao Gao 
> Signed-off-by: Lan Tianyu 
> ---
>  docs/man/xl.cfg.pod.5.in| 34 ++-
>  tools/libxl/libxl_types.idl | 16 +++
>  tools/xl/xl_parse.c | 66 
> +
>  3 files changed, 115 insertions(+), 1 deletion(-)
> 
> diff --git a/docs/man/xl.cfg.pod.5.in b/docs/man/xl.cfg.pod.5.in
> index 79cb2ea..f259e22 100644
> --- a/docs/man/xl.cfg.pod.5.in
> +++ b/docs/man/xl.cfg.pod.5.in
> @@ -1545,7 +1545,39 @@ Do not provide a VM generation ID.
>  See also "Virtual Machine Generation ID" by Microsoft:
>  L
>  
> -=back 
> +=back

No spurious changes. Leave the extra " " as is.

> +
> +=item 

Re: [Xen-devel] [PATCH V2 7/25] tools/libacpi: Add new fields in acpi_config for DMAR table

[Roger Pau Monné]

On Wed, Aug 09, 2017 at 04:34:08PM -0400, Lan Tianyu wrote:
> From: Chao Gao 
> 
> The BIOS reports the remapping hardware units in a platform to system software
> through the DMA Remapping Reporting (DMAR) ACPI table.
> New fields are introduces for DMAR table. These new fields are set by
  ^ s/s/d/ to libacpi
> toolstack through parsing guest's config file. construct_dmar() is added to
> build DMAR table according to the new fields.
> 
> Signed-off-by: Chao Gao 
> Signed-off-by: Lan Tianyu 
> ---
>  tools/libacpi/build.c   | 57 
> +
>  tools/libacpi/libacpi.h |  9 
>  2 files changed, 66 insertions(+)
> 
> diff --git a/tools/libacpi/build.c b/tools/libacpi/build.c
> index f9881c9..c7cc784 100644
> --- a/tools/libacpi/build.c
> +++ b/tools/libacpi/build.c
> @@ -28,6 +28,10 @@
>  
>  #define ACPI_MAX_SECONDARY_TABLES 16

A comment about the meaning of the defines below might be helpful.

> +#define VTD_HOST_ADDRESS_WIDTH 39
> +#define I440_PSEUDO_BUS_PLATFORM 0xff
> +#define I440_PSEUDO_DEVFN_IOAPIC 0x0
> +
>  #define align16(sz)(((sz) + 15) & ~15)
>  #define fixed_strcpy(d, s) strncpy((d), (s), sizeof(d))
>  
> @@ -303,6 +307,59 @@ static struct acpi_20_slit *construct_slit(struct 
> acpi_ctxt *ctxt,
>  return slit;
>  }
>  
> +/*
> + * Only one DMA remapping hardware unit is exposed and all devices
> + * are under the remapping hardware unit. I/O APIC should be explicitly
> + * enumerated.
> + */
> +struct acpi_dmar *construct_dmar(struct acpi_ctxt *ctxt,
> + const struct acpi_config *config)
> +{
> +struct acpi_dmar *dmar;
> +struct acpi_dmar_hardware_unit *drhd;
> +struct dmar_device_scope *scope;
> +unsigned int size;
> +unsigned int ioapic_scope_size = sizeof(*scope) + sizeof(scope->path[0]);
> +
> +size = sizeof(*dmar) + sizeof(*drhd) + ioapic_scope_size;
> +
> +dmar = ctxt->mem_ops.alloc(ctxt, size, 16);
> +if ( !dmar )
> +return NULL;
> +
> +memset(dmar, 0, size);
> +dmar->header.signature = ACPI_2_0_DMAR_SIGNATURE;
> +dmar->header.revision = ACPI_2_0_DMAR_REVISION;
> +dmar->header.length = size;
> +fixed_strcpy(dmar->header.oem_id, ACPI_OEM_ID);
> +fixed_strcpy(dmar->header.oem_table_id, ACPI_OEM_TABLE_ID);
> +dmar->header.oem_revision = ACPI_OEM_REVISION;
> +dmar->header.creator_id   = ACPI_CREATOR_ID;
> +dmar->header.creator_revision = ACPI_CREATOR_REVISION;
> +dmar->host_address_width = VTD_HOST_ADDRESS_WIDTH - 1;
> +if ( config->iommu_intremap_supported )
> +dmar->flags = ACPI_DMAR_INTR_REMAP;

Since you initialize flags to 0 I would use |= here, in case this gets
moved later and this is not the first flag to be set.

> +if ( !config->iommu_x2apic_supported )
> +dmar->flags |= ACPI_DMAR_X2APIC_OPT_OUT;

I'm not sure of the reason behind not supporting x2APIC mode (I've
already commented in another patch).

> +drhd = (struct acpi_dmar_hardware_unit *)((void*)dmar + sizeof(*dmar));
> +drhd->type = ACPI_DMAR_TYPE_HARDWARE_UNIT;
> +drhd->length = sizeof(*drhd) + ioapic_scope_size;
> +drhd->flags = ACPI_DMAR_INCLUDE_PCI_ALL;
> +drhd->pci_segment = 0;
> +drhd->base_address = config->iommu_base_addr;
> +
> +scope = >scope[0];
> +scope->type = ACPI_DMAR_DEVICE_SCOPE_IOAPIC;
> +scope->length = ioapic_scope_size;
> +scope->enumeration_id = config->ioapic_id;
> +scope->bus = I440_PSEUDO_BUS_PLATFORM;
> +scope->path[0] = I440_PSEUDO_DEVFN_IOAPIC;

I'm not sure whether this constants should instead be fields in the
acpi_config struct passed down from libxl. libxc shouldn't really need
to know anything about which chipset a VM is using.

> +set_checksum(dmar, offsetof(struct acpi_header, checksum), size);
> +return dmar;
> +}
> +
>  static int construct_passthrough_tables(struct acpi_ctxt *ctxt,
>  unsigned long *table_ptrs,
>  int nr_tables,
> diff --git a/tools/libacpi/libacpi.h b/tools/libacpi/libacpi.h
> index 2ed1ecf..74778a5 100644
> --- a/tools/libacpi/libacpi.h
> +++ b/tools/libacpi/libacpi.h
> @@ -20,6 +20,8 @@
>  #ifndef __LIBACPI_H__
>  #define __LIBACPI_H__
>  
> +#include 
> +
>  #define ACPI_HAS_COM1  (1<<0)
>  #define ACPI_HAS_COM2  (1<<1)
>  #define ACPI_HAS_LPT1  (1<<2)
> @@ -96,8 +98,15 @@ struct acpi_config {
>  uint32_t ioapic_base_address;
>  uint16_t pci_isa_irq_mask;
>  uint8_t ioapic_id;
> +
> +/* Emulated IOMMU features and location */
> +bool iommu_intremap_supported;
> +bool iommu_x2apic_supported;
> +uint64_t iommu_base_addr;
>  };
>  
> +struct acpi_dmar *construct_dmar(struct acpi_ctxt *ctxt,
> + const struct acpi_config *config);
>  int acpi_build_tables(struct 

Re: [Xen-devel] [PATCH V2 5/25] tools/libxc: Add viommu operations in libxc

[Roger Pau Monné]

On Wed, Aug 09, 2017 at 04:34:06PM -0400, Lan Tianyu wrote:
> From: Chao Gao 
> 
> This patch adds XEN_DOMCTL_viommu_op hypercall. This hypercall
> comprises three sub-command:
 ^ s
> - query capabilities of one specific type vIOMMU emulated by Xen
   ^ of
> - create vIOMMU in Xen hypervisor, given viommu type, register-set location
  ^ a^s/hypervisor//
> and capabilities
> - destroy vIOMMU specified by viommu_id
   ^ a
> 
> Signed-off-by: Chao Gao 
> Signed-off-by: Lan Tianyu 
> ---
>  tools/libxc/Makefile  |  1 +
>  tools/libxc/include/xenctrl.h |  8 +
>  tools/libxc/xc_viommu.c   | 81 
> +++
>  3 files changed, 90 insertions(+)
>  create mode 100644 tools/libxc/xc_viommu.c
> 
> diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
> index 28b1857..8724df5 100644
> --- a/tools/libxc/Makefile
> +++ b/tools/libxc/Makefile
> @@ -51,6 +51,7 @@ CTRL_SRCS-$(CONFIG_MiniOS) += xc_minios.c
>  CTRL_SRCS-y   += xc_evtchn_compat.c
>  CTRL_SRCS-y   += xc_gnttab_compat.c
>  CTRL_SRCS-y   += xc_devicemodel_compat.c
> +CTRL_SRCS-y   += xc_viommu.c
>  
>  GUEST_SRCS-y :=
>  GUEST_SRCS-y += xg_private.c xc_suspend.c
> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> index bde8313..dfaa9d5 100644
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -27,6 +27,7 @@
>  #define __XEN_TOOLS__ 1
>  #endif
>  
> +#include 

I don't see the need for this include.

>  #include 
>  #include 
>  #include 
> @@ -2499,6 +2500,13 @@ enum xc_static_cpu_featuremask {
>  const uint32_t *xc_get_static_cpu_featuremask(enum 
> xc_static_cpu_featuremask);
>  const uint32_t *xc_get_feature_deep_deps(uint32_t feature);
>  
> +int xc_viommu_query_cap(xc_interface *xch, domid_t dom,
> +uint64_t type, uint64_t *cap);
> +int xc_viommu_create(xc_interface *xch, domid_t dom, uint64_t type,
> + uint64_t base_addr, uint64_t length, uint64_t cap,
> + uint32_t *viommu_id);
> +int xc_viommu_destroy(xc_interface *xch, domid_t dom, uint32_t viommu_id);
> +
>  #endif
>  
>  int xc_livepatch_upload(xc_interface *xch,
> diff --git a/tools/libxc/xc_viommu.c b/tools/libxc/xc_viommu.c
> new file mode 100644
> index 000..04aae96
> --- /dev/null
> +++ b/tools/libxc/xc_viommu.c
> @@ -0,0 +1,81 @@
> +/*
> + * xc_viommu.c
> + *
> + * viommu related API functions.
> + *
> + * Copyright (C) 2017 Intel Corporation
> + *
> + * This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License, version 2.1, as published by the Free Software Foundation.
> + *
> + * This library is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with this library; If not, see 
> .
> + */
> +
> +#include "xc_private.h"
> +
> +int xc_viommu_query_cap(xc_interface *xch, domid_t dom,
> +uint64_t type, uint64_t *cap)
> +{
> +int rc;
> +DECLARE_DOMCTL;
> +
> +domctl.cmd = XEN_DOMCTL_viommu_op;
> +domctl.domain = (domid_t)dom;

Pointless cast.

> +domctl.u.viommu_op.cmd = XEN_DOMCTL_query_viommu_caps;
> +domctl.u.viommu_op.u.query_caps.viommu_type = type;
> +
> +rc = do_domctl(xch, );
> +if ( !rc )
> +*cap = domctl.u.viommu_op.u.query_caps.capabilities;
> +return rc;
> +}
> +
> +int xc_viommu_create(xc_interface *xch, domid_t dom, uint64_t type,
> + uint64_t base_addr, uint64_t length, uint64_t cap,
> + uint32_t *viommu_id)
> +{
> +int rc;
> +DECLARE_DOMCTL;
> +
> +domctl.cmd = XEN_DOMCTL_viommu_op;
> +domctl.domain = (domid_t)dom;

Pointless cast.

> +domctl.u.viommu_op.cmd = XEN_DOMCTL_create_viommu;
> +domctl.u.viommu_op.u.create_viommu.viommu_type = type;
> +domctl.u.viommu_op.u.create_viommu.base_address = base_addr;
> +domctl.u.viommu_op.u.create_viommu.length = length;
> +domctl.u.viommu_op.u.create_viommu.capabilities = cap;
> +
> +rc = do_domctl(xch, );
> +if ( !rc )
> +*viommu_id = domctl.u.viommu_op.u.create_viommu.viommu_id;
> +return rc;
> +}
> +
> +int xc_viommu_destroy(xc_interface *xch, domid_t dom, uint32_t viommu_id)
> +{
> +DECLARE_DOMCTL;
> +
> +domctl.cmd = XEN_DOMCTL_viommu_op;
> +domctl.domain = (domid_t)dom;
> +domctl.u.viommu_op.cmd = XEN_DOMCTL_destroy_viommu;
> +domctl.u.viommu_op.u.destroy_viommu.viommu_id = viommu_id;
> +
> +return do_domctl(xch, 

Re: [Xen-devel] [PATCH 1/5] ARM: ITS: Introduce common function add_to_host_its_list

[Julien Grall]

Hello,

On 13/08/17 22:30, mja...@caviumnetworks.com wrote:

From: Manish Jaggi 

add_to_host_its_list will update the host_its_list. This common function to
be invoked from gicv3_its_dt_init and gic_v3_its_acpi_init.

Signed-off-by: Manish Jaggi 
---
 xen/arch/arm/gic-v3-its.c | 36 +++-
 1 file changed, 23 insertions(+), 13 deletions(-)

diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index 2d36030..f844a0d 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -976,12 +976,31 @@ int gicv3_its_make_hwdom_dt_nodes(const struct domain *d,
 return res;
 }

+/* Common function for adding to host_its_list */
+static int add_to_host_its_list(u64 addr, u64 size, const void *node)


Why void *? node will be always assigned to dt_node and we should keep 
some type safety.


Also this function only return -1 or 0. Please use boolean.


+{
+struct host_its *its_data;


Missing newline between the declaration and the code.


+its_data = xzalloc(struct host_its);
+
+if ( !its_data )
+return -1;
+
+its_data->addr = addr;
+its_data->size = size;
+if ( node )


This check is pointless. If it is NULL then dt_node will be NULL and 
this is what we want.



+its_data->dt_node = node;
+
+printk("GICv3: Found ITS @0x%lx\n", addr);
+
+list_add_tail(_data->entry, _its_list);
+
+return 0;
+}
+
 /* Scan the DT for any ITS nodes and create a list of host ITSes out of it. */
 void gicv3_its_dt_init(const struct dt_device_node *node)
 {
 const struct dt_device_node *its = NULL;
-struct host_its *its_data;
-


Why this newline is dropped?


 /*
  * Check for ITS MSI subnodes. If any, add the ITS register
  * frames to the ITS list.
@@ -996,17 +1015,8 @@ void gicv3_its_dt_init(const struct dt_device_node *node)
 if ( dt_device_get_address(its, 0, , ) )
 panic("GICv3: Cannot find a valid ITS frame address");

-its_data = xzalloc(struct host_its);
-if ( !its_data )
-panic("GICv3: Cannot allocate memory for ITS frame");
-
-its_data->addr = addr;
-its_data->size = size;
-its_data->dt_node = its;
-
-printk("GICv3: Found ITS @0x%lx\n", addr);
-
-list_add_tail(_data->entry, _its_list);
+if ( add_to_host_its_list(addr, size, its) )
+panic("GICV3: Adding Host ITS failed ");
 }
 }




Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 12/27] xen/arm: Introduce hsr_xabt to gather common bits between hsr_dabt and

[Andre Przywara]

Hi,

On 14/08/17 15:24, Julien Grall wrote:
> This will allow to consolidate some part of the data abort and prefetch
> abort handling in a single function later on.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Andre Przywara 

Cheers,
Andre.

> ---
>  xen/include/asm-arm/processor.h | 13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
> index 3ef606c554..9964348189 100644
> --- a/xen/include/asm-arm/processor.h
> +++ b/xen/include/asm-arm/processor.h
> @@ -537,6 +537,19 @@ union hsr {
>  unsigned long ec:6;/* Exception Class */
>  } dabt; /* HSR_EC_DATA_ABORT_* */
>  
> +/* Contain the common bits between DABT and IABT */
> +struct hsr_xabt {
> +unsigned long fsc:6;/* Fault status code */
> +unsigned long pad1:1;
> +unsigned long s1ptw:1;  /* Stage 2 fault during stage 1 translation 
> */
> +unsigned long pad2:1;
> +unsigned long eat:1;/* External abort type */
> +unsigned long fnv:1;/* FAR not Valid */
> +unsigned long pad3:14;
> +unsigned long len:1;/* Instruction length */
> +unsigned long ec:6; /* Exception Class */
> +} xabt;
> +
>  #ifdef CONFIG_ARM_64
>  struct hsr_brk {
>  unsigned long comment:16;   /* Comment */
> 

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

Re: [Xen-devel] [PATCH] xen/events: events_fifo: Don't use {get, put}_cpu() in xen_evtchn_fifo_init()

[Julien Grall]

Hi,

Gentle ping. This patch was reviewed but not queued. Are we waiting for 
other reviewed?


Cheers,

On 18/08/17 11:15, Julien Grall wrote:

Hi Boris,

On 17/08/17 18:36, Boris Ostrovsky wrote:

On 08/17/2017 12:14 PM, Julien Grall wrote:

When booting Linux as Xen guest with CONFIG_DEBUG_ATOMIC, the following
splat appears:

[0.002323] Mountpoint-cache hash table entries: 1024 (order: 1,
8192 bytes)
[0.019717] ASID allocator initialised with 65536 entries
[0.020019] xen:grant_table: Grant tables using version 1 layout
[0.020051] Grant table initialized
[0.020069] BUG: sleeping function called from invalid context at
/data/src/linux/mm/page_alloc.c:4046
[0.020100] in_atomic(): 1, irqs_disabled(): 0, pid: 1, name:
swapper/0
[0.020123] no locks held by swapper/0/1.
[0.020143] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.13.0-rc5 #598
[0.020166] Hardware name: FVP Base (DT)
[0.020182] Call trace:
[0.020199] [] dump_backtrace+0x0/0x270
[0.020222] [] show_stack+0x24/0x30
[0.020244] [] dump_stack+0xb8/0xf0
[0.020267] [] ___might_sleep+0x1c8/0x1f8
[0.020291] [] __might_sleep+0x58/0x90
[0.020313] [] __alloc_pages_nodemask+0x1c0/0x12e8
[0.020338] [] alloc_page_interleave+0x38/0x88
[0.020363] [] alloc_pages_current+0xdc/0xf0
[0.020387] [] __get_free_pages+0x28/0x50
[0.020411] []
evtchn_fifo_alloc_control_block+0x2c/0xa0
[0.020437] [] xen_evtchn_fifo_init+0x38/0xb4
[0.020461] [] xen_init_IRQ+0x44/0xc8
[0.020484] [] xen_guest_init+0x250/0x300
[0.020507] [] do_one_initcall+0x44/0x130
[0.020531] [] kernel_init_freeable+0x120/0x288
[0.020556] [] kernel_init+0x18/0x110
[0.020578] [] ret_from_fork+0x10/0x40
[0.020606] xen:events: Using FIFO-based ABI
[0.020658] Xen: initializing cpu0
[0.027727] Hierarchical SRCU implementation.
[0.036235] EFI services will not be available.
[0.043810] smp: Bringing up secondary CPUs ...

This is because get_cpu() in xen_evtchn_fifo_init() will disable
preemption, but __get_free_page() might sleep (GFP_ATOMIC is not set).

xen_evtchn_fifo_init() will always be called before SMP is initialized,
so {get,put}_cpu() could be replaced by a simple smp_processor_id().


On x86 this will be called out of init_IRQ(), which is already preceded
by preempt_disable().


Well the main problem is preempt_disable() itself. in_atomic() will
check preempt_count and return 1 if it is non-zero.

__get_free_page might sleep if GFP_ATOMIC is not set and therefore you
will see the splat when CONFIG_DEBUG_ATOMIC is enabled. However, those
checks don't happen before the scheduler is setup. Hence why you don't
see the error on x86.

Cheers,



Reviewed-by: Boris Ostrovsky 





--
Julien Grall

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

Re: [Xen-devel] [PATCH 11/27] xen/arm: Add FnV field in hsr_*abt

[Andre Przywara]

Hi,

On 14/08/17 15:24, Julien Grall wrote:
> FnV (FAR not Valid) bit was introduced by ARMv8 in both AArch32 and
> AArch64 (See D7-2275, D7-2277, G6-4958, G6-4962 in ARM DDI 0487B.a).

I understand that this just prepares the data structures for patch #14,
but I was wondering if we should update the other fields on the way as
well, for instance there is now "ar" in Aarch32 also.

> Signed-off-by: Julien Grall 

But the actual bits are correct, so if we just need "fnv", then this is:

Reviewed-by: Andre Przywara 

> ---
>  xen/include/asm-arm/processor.h | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
> index 51645f08c0..3ef606c554 100644
> --- a/xen/include/asm-arm/processor.h
> +++ b/xen/include/asm-arm/processor.h
> @@ -509,7 +509,8 @@ union hsr {
>  unsigned long s1ptw:1; /* Stage 2 fault during stage 1 translation */
>  unsigned long res1:1;  /* RES0 */
>  unsigned long eat:1;   /* External abort type */
> -unsigned long res2:15;
> +unsigned long fnv:1;   /* FAR not Valid */
> +unsigned long res2:14;
>  unsigned long len:1;   /* Instruction length */
>  unsigned long ec:6;/* Exception Class */
>  } iabt; /* HSR_EC_INSTR_ABORT_* */
> @@ -520,10 +521,11 @@ union hsr {
>  unsigned long s1ptw:1; /* Stage 2 fault during stage 1 translation */
>  unsigned long cache:1; /* Cache Maintenance */
>  unsigned long eat:1;   /* External Abort Type */
> +unsigned long fnv:1;   /* FAR not Valid */
>  #ifdef CONFIG_ARM_32
> -unsigned long sbzp0:6;
> +unsigned long sbzp0:5;

This can be broken down further, as the ARMv8 ARM explains more of these
bits now. "ar" is now also defined here, for instance.

>  #else
> -unsigned long sbzp0:4;
> -unsigned long sbzp0:3;

And also on the Aarch64 side there are now more bits used.

Cheers,
Andre.

>  unsigned long ar:1;/* Acquire Release */
>  unsigned long sf:1;/* Sixty Four bit register */
>  #endif
> 

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

Re: [Xen-devel] [PATCH V2 4/25] Xen/doc: Add Xen virtual IOMMU doc

[Roger Pau Monné]

On Wed, Aug 09, 2017 at 04:34:05PM -0400, Lan Tianyu wrote:
> This patch is to add Xen virtual IOMMU doc to introduce motivation,
> framework, vIOMMU hypercall and xl configuration.
> 
> Signed-off-by: Lan Tianyu 
> ---
>  docs/misc/viommu.txt | 139 
> +++
>  1 file changed, 139 insertions(+)
>  create mode 100644 docs/misc/viommu.txt
> 
> diff --git a/docs/misc/viommu.txt b/docs/misc/viommu.txt
> new file mode 100644
> index 000..39455bb
> --- /dev/null
> +++ b/docs/misc/viommu.txt

IMHO, this should be the first patch in the series.

> @@ -0,0 +1,139 @@
> +Xen virtual IOMMU
> +
> +Motivation
> +==
> +*) Enable more than 255 vcpu support

Seems like the "*)" is some kind of leftover?

> +HPC cloud service requires VM provides high performance parallel
> +computing and we hope to create a huge VM with >255 vcpu on one machine
> +to meet such requirement. Pin each vcpu to separate pcpus.

I would re-write this as:

The current requirements of HPC cloud service requires VM with a high
number of CPUs in order to achieve high performance in parallel
computing.

Also, this is needed in order to create VMs with > 128 vCPUs, not 255
vCPUs. That's because the APIC ID used by Xen is CPU ID * 2 (ie: CPU
127 has APIC ID 254, which is the last one available in xAPIC mode).
You should reword the paragraphs below in order to fix the mention of
255 vCPUs.

> +
> +To support >255 vcpus, X2APIC mode in guest is necessary because legacy
> +APIC(XAPIC) just supports 8-bit APIC ID and it only can support 255
> +vcpus at most. X2APIC mode supports 32-bit APIC ID and it requires
> +interrupt mapping function of vIOMMU.

Correct me if I'm wrong, but I don't think x2APIC requires vIOMMU. The
IOMMU is required so that you can route interrupts to all the possible
CPUs. One could image a setup where only CPUs with APIC IDs < 255 are
used as targets of external interrupts, and that doesn't require a
IOMMU.

> +The reason for this is that there is no modification to existing PCI MSI
> +and IOAPIC with the introduction of X2APIC. PCI MSI/IOAPIC can only send
> +interrupt message containing 8-bit APIC ID, which cannot address >255
> +cpus. Interrupt remapping supports 32-bit APIC ID and so it's necessary
> +to enable >255 cpus with x2apic mode.
> +
> +
> +vIOMMU Architecture
> +===
> +vIOMMU device model is inside Xen hypervisor for following factors
> +1) Avoid round trips between Qemu and Xen hypervisor
> +2) Ease of integration with the rest of hypervisor
> +3) HVMlite/PVH doesn't use Qemu
> +
> +* Interrupt remapping overview.
> +Interrupts from virtual devices and physical devices are delivered
> +to vLAPIC from vIOAPIC and vMSI. vIOMMU needs to remap interrupt during
> +this procedure.
> +
> ++---+
> +|Qemu   |VM |
> +|   | ++|
> +|   | |  Device driver ||
> +|   | ++---+|
> +|   |  ^|
> +|   ++  | ++---+|
> +|   | Virtual device |  | |  IRQ subsystem ||
> +|   +---++  | ++---+|
> +|   |   |  ^|
> +|   |   |  ||
> ++---+---+
> +|hypervisor |  | VIRQ   |
> +|   |+-++   |
> +|   ||  vLAPIC  |   |
> +|   |VIRQ+-++   |
> +|   |  ^|
> +|   |  ||
> +|   |+-++   |
> +|   ||  vIOMMU  |   |
> +|   |+-++   |
> +|   |  ^|
> +|   |  ||
> +|   |+-++   |
> +|   ||   vIOAPIC/vMSI   |   |
> +|   |++++   |
> +|   | ^^|
> +|   +-+||
> +|  ||
> ++---+
> +HW |IRQ
> ++---+
> +|   PCI Device  |
> ++---+
> +
> +
> +vIOMMU hypercall
> +
> +Introduce new domctl hypercall "xen_domctl_viommu_op" to create/destroy
^ a
> +vIOMMU and query vIOMMU capabilities that device model can support.
 ^ s 

[Xen-devel] [xtf test] 112790: all pass - PUSHED

[osstest service owner]

flight 112790 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112790/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 xtf  b369b8f9cc89f906deba9ae1b1a6d27ac745cf2d
baseline version:
 xtf  24635d9265e70b2d75a17f2cfc0c2ca0fad5843b

Last test of basis   112645  2017-08-15 10:46:41 Z7 days
Testing same since   112790  2017-08-21 17:14:56 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 

jobs:
 build-amd64-xtf  pass
 build-amd64  pass
 build-amd64-pvopspass
 test-xtf-amd64-amd64-1   pass
 test-xtf-amd64-amd64-2   pass
 test-xtf-amd64-amd64-3   pass
 test-xtf-amd64-amd64-4   pass
 test-xtf-amd64-amd64-5   pass



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

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

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.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=xtf
+ revision=b369b8f9cc89f906deba9ae1b1a6d27ac745cf2d
+ . ./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 xtf 
b369b8f9cc89f906deba9ae1b1a6d27ac745cf2d
+ branch=xtf
+ revision=b369b8f9cc89f906deba9ae1b1a6d27ac745cf2d
+ . ./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=xtf
+ xenbranch=xen-unstable
+ '[' xxtf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.9-testing
+ '[' xb369b8f9cc89f906deba9ae1b1a6d27ac745cf2d = 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
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-4.9
++ : tested/linux-arm-xen
++ '[' 

Re: [Xen-devel] [PATCH v2 3/3] tools/libxc: use superpages during restore of HVM guest

[Olaf Hering]

On Tue, Aug 22, Wei Liu wrote:

> On Thu, Aug 17, 2017 at 07:01:33PM +0200, Olaf Hering wrote:
> > +/* No superpage in 1st 2MB due to VGA hole */
> > +xc_sr_set_bit(0, >x86_hvm.restore.attempted_1g);
> > +xc_sr_set_bit(0, >x86_hvm.restore.attempted_2m);
> I don't quite get this. What about other holes such as MMIO?

This just copies what meminit_hvm does. Is there a way to know where the
MMIO hole is? Maybe I just missed the MMIO part. In the worst case I
think a super page is allocated, which is later split into single pages.

> One potential issue I can see with your algorithm is, if the stream of
> page info contains pages from different super pages, the risk of going
> over memory limit is high (hence failing the migration).
> 
> Is my concern unfounded?

In my testing I have seen the case of over-allocation. Thats why I
implemented the freeing of unpopulated parts. It would be nice to know
how many pages are actually coming. I think this info is not available.

On the other side, the first iteration sends the pfns linear. This is
when the allocation actually happens. So the over-allocation will only
trigger near the end, if a 1G range is allocated but only a few pages
will be stored into this range.

Olaf


signature.asc
Description: PGP signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V2 3/25] VIOMMU: Add get irq info callback to convert irq remapping request

[Roger Pau Monné]

On Wed, Aug 09, 2017 at 04:34:04PM -0400, Lan Tianyu wrote:
> This patch is to add get_irq_info callback for platform implementation
> to convert irq remapping request to irq info (E,G vector, dest, dest_mode
> and so on).
> 
> Signed-off-by: Lan Tianyu 
> ---
>  xen/common/viommu.c  | 16 
>  xen/include/asm-x86/viommu.h |  8 
>  xen/include/xen/viommu.h |  9 +
>  3 files changed, 33 insertions(+)
> 
> diff --git a/xen/common/viommu.c b/xen/common/viommu.c
> index f4d34e6..03c879d 100644
> --- a/xen/common/viommu.c
> +++ b/xen/common/viommu.c
> @@ -213,6 +213,22 @@ int viommu_handle_irq_request(struct domain *d, u32 
> viommu_id,
>  return info->viommu[viommu_id]->ops->handle_irq_request(d, request);
>  }
>  
> +int viommu_get_irq_info(struct domain *d, u32 viommu_id,
> +struct irq_remapping_request *request,
> +struct irq_remapping_info *irq_info)

The definition of this struct seems to be arch-specific, in which case
IMHO it should be called arch_irq_remapping_info, in order to denote
it's arch-specific.

> +{
> +struct viommu_info *info = >viommu;
> +
> +if ( viommu_id >= info->nr_viommu
> + || !info->viommu[viommu_id] )

Unneeded line break.

Roger.

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

Re: [Xen-devel] [PATCH V2 2/25] VIOMMU: Add irq request callback to deal with irq remapping

[Roger Pau Monné]

On Wed, Aug 09, 2017 at 04:34:03PM -0400, Lan Tianyu wrote:
> This patch is to add irq request callback for platform implementation
> to deal with irq remapping request.
> 
> Signed-off-by: Lan Tianyu 
> ---
>  xen/common/viommu.c  | 15 +
>  xen/include/asm-x86/viommu.h | 73 
> 
>  xen/include/xen/viommu.h |  9 ++
>  3 files changed, 97 insertions(+)
>  create mode 100644 xen/include/asm-x86/viommu.h
> 
> diff --git a/xen/common/viommu.c b/xen/common/viommu.c
> index a4d004d..f4d34e6 100644
> --- a/xen/common/viommu.c
> +++ b/xen/common/viommu.c
> @@ -198,6 +198,21 @@ int __init viommu_setup(void)
>  return 0;
>  }
>  
> +int viommu_handle_irq_request(struct domain *d, u32 viommu_id,
> +  struct irq_remapping_request *request)
> +{
> +struct viommu_info *info = >viommu;
> +
> +if ( viommu_id >= info->nr_viommu
> + || !info->viommu[viommu_id] )

This fits on the same line, no need to split it.

> +return -EINVAL;
> +
> +if ( !info->viommu[viommu_id]->ops->handle_irq_request )
> +return -EINVAL;
> +
> +return info->viommu[viommu_id]->ops->handle_irq_request(d, request);
> +}
> +
>  /*
>   * Local variables:
>   * mode: C
> diff --git a/xen/include/asm-x86/viommu.h b/xen/include/asm-x86/viommu.h
> new file mode 100644
> index 000..51bda72
> --- /dev/null
> +++ b/xen/include/asm-x86/viommu.h
> @@ -0,0 +1,73 @@
> +/*
> + * include/asm-x86/viommu.h
> + *
> + * Copyright (c) 2017 Intel Corporation.
> + * Author: Lan Tianyu  
> + *
> + * 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 .
> + *
> + */
> +#ifndef __ARCH_X86_VIOMMU_H__
> +#define __ARCH_X86_VIOMMU_H__
> +
> +#include 
> +#include 
> +
> +/* IRQ request type */
> +#define VIOMMU_REQUEST_IRQ_MSI  0
> +#define VIOMMU_REQUEST_IRQ_APIC 1
> +
> +struct irq_remapping_request
> +{
> +union {
> +/* MSI */
> +struct {
> +u64 addr;
> +u32 data;
> +} msi;
> +/* Redirection Entry in IOAPIC */
> +u64 rte;
> +} msg;
> +u16 source_id;
> +u8 type;
> +};
> +
> +static inline void irq_request_ioapic_fill(struct irq_remapping_request *req,
> + uint32_t ioapic_id, uint64_t rte)
> +{
> +ASSERT(req);
> +req->type = VIOMMU_REQUEST_IRQ_APIC;
> +req->source_id = ioapic_id;
> +req->msg.rte = rte;
> +}
> +
> +static inline void irq_request_msi_fill(struct irq_remapping_request *req,
> +  uint32_t source_id, uint64_t addr, uint32_t data)
> +{
> +ASSERT(req);
> +req->type = VIOMMU_REQUEST_IRQ_MSI;
> +req->source_id = source_id;
> +req->msg.msi.addr = addr;
> +req->msg.msi.data = data;
> +}

What's the usage of those two functions? AFAICT they don't have any
callers in this patch.

> +
> +#endif /* __ARCH_X86_VIOMMU_H__ */
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: "BSD"
> + * c-basic-offset: 4
> + * tab-width: 4
> + * End:
> + */
> diff --git a/xen/include/xen/viommu.h b/xen/include/xen/viommu.h
> index 527afb1..0be1b3a 100644
> --- a/xen/include/xen/viommu.h
> +++ b/xen/include/xen/viommu.h
> @@ -20,6 +20,8 @@
>  #ifndef __XEN_VIOMMU_H__
>  #define __XEN_VIOMMU_H__
>  
> +#include 
> +
>  #define NR_VIOMMU_PER_DOMAIN 1
>  
>  struct viommu;
> @@ -28,6 +30,8 @@ struct viommu_ops {
>  u64 (*query_caps)(struct domain *d);
>  int (*create)(struct domain *d, struct viommu *viommu);
>  int (*destroy)(struct viommu *viommu);
> +int (*handle_irq_request)(struct domain *d,
> +  struct irq_remapping_request *request);

I'm slightly lost, you add the function pointer here and some inline
functions in asm-x86/viommu.h, yet I don't see them being hooked into
the struct viommu_ops in any way.

Roger.

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

Re: [Xen-devel] [PATCH v2 3/3] tools/libxc: use superpages during restore of HVM guest

[Wei Liu]

On Thu, Aug 17, 2017 at 07:01:33PM +0200, Olaf Hering wrote:
[...]
> diff --git a/tools/libxc/xc_sr_restore_x86_hvm.c 
> b/tools/libxc/xc_sr_restore_x86_hvm.c
> index 1dca85354a..60454148db 100644
> --- a/tools/libxc/xc_sr_restore_x86_hvm.c
> +++ b/tools/libxc/xc_sr_restore_x86_hvm.c
> @@ -135,6 +135,8 @@ static int x86_hvm_localise_page(struct xc_sr_context 
> *ctx,
>  static int x86_hvm_setup(struct xc_sr_context *ctx)
>  {
>  xc_interface *xch = ctx->xch;
> +struct xc_sr_bitmap *bm;
> +unsigned long bits;
>  
>  if ( ctx->restore.guest_type != DHDR_TYPE_X86_HVM )
>  {
> @@ -149,7 +151,30 @@ static int x86_hvm_setup(struct xc_sr_context *ctx)
>  return -1;
>  }
>  
> +bm = >x86_hvm.restore.attempted_1g;
> +bits = (ctx->restore.p2m_size >> SUPERPAGE_1GB_SHIFT) + 1;
> +if ( xc_sr_bitmap_resize(bm, bits) == false )
> +goto out;
> +
> +bm = >x86_hvm.restore.attempted_2m;
> +bits = (ctx->restore.p2m_size >> SUPERPAGE_2MB_SHIFT) + 1;
> +if ( xc_sr_bitmap_resize(bm, bits) == false )
> +goto out;
> +
> +bm = >x86_hvm.restore.allocated_pfns;
> +bits = ctx->restore.p2m_size + 1;
> +if ( xc_sr_bitmap_resize(bm, bits) == false )
> +goto out;
> +
> +/* No superpage in 1st 2MB due to VGA hole */
> +xc_sr_set_bit(0, >x86_hvm.restore.attempted_1g);
> +xc_sr_set_bit(0, >x86_hvm.restore.attempted_2m);
> +

I don't quite get this. What about other holes such as MMIO?

>  return 0;
> +
> +out:
> +ERROR("Unable to allocate memory for pfn bitmaps");
> +return -1;
>  }
>  
>  /*
> @@ -224,10 +249,164 @@ static int x86_hvm_stream_complete(struct 
> xc_sr_context *ctx)
>  static int x86_hvm_cleanup(struct xc_sr_context *ctx)
>  {
>  free(ctx->x86_hvm.restore.context);
> +xc_sr_bitmap_free(>x86_hvm.restore.attempted_1g);
> +xc_sr_bitmap_free(>x86_hvm.restore.attempted_2m);
> +xc_sr_bitmap_free(>x86_hvm.restore.allocated_pfns);
>  
>  return 0;
>  }
>  
> +/*
> + * Set a pfn as allocated, expanding the tracking structures if needed.
> + */
> +static int pfn_set_allocated(struct xc_sr_context *ctx, xen_pfn_t pfn)
> +{
> +xc_interface *xch = ctx->xch;
> +
> +if ( !xc_sr_set_bit(pfn, >x86_hvm.restore.allocated_pfns) )
> +{
> +ERROR("Failed to realloc allocated_pfns bitmap");
> +errno = ENOMEM;
> +return -1;
> +}
> +return 0;
> +}
> +
> +/*
> + * Attempt to allocate a superpage where the pfn resides.
> + */
> +static int x86_hvm_allocate_pfn(struct xc_sr_context *ctx, xen_pfn_t pfn)
> +{
> +xc_interface *xch = ctx->xch;
> +bool success = false;
> +int rc = -1, done;
> +unsigned int order;
> +unsigned long i;
> +unsigned long stat_1g = 0, stat_2m = 0, stat_4k = 0;
> +unsigned long idx_1g, idx_2m;
> +unsigned long count;
> +xen_pfn_t base_pfn = 0, extnt;
> +
> +if (xc_sr_test_bit(pfn, >x86_hvm.restore.allocated_pfns))

Style is wrong here and in some other places.

> +return 0;
> +
> +idx_1g = pfn >> SUPERPAGE_1GB_SHIFT;
> +idx_2m = pfn >> SUPERPAGE_2MB_SHIFT;
> +if (!xc_sr_bitmap_resize(>x86_hvm.restore.attempted_1g, idx_1g))
> +{
> +PERROR("Failed to realloc attempted_1g");
> +return -1;
> +}
> +if (!xc_sr_bitmap_resize(>x86_hvm.restore.attempted_2m, idx_2m))
> +{
> +PERROR("Failed to realloc attempted_2m");
> +return -1;
> +}
> +DPRINTF("idx_1g %lu idx_2m %lu\n", idx_1g, idx_2m);
> +if (!xc_sr_test_and_set_bit(idx_1g, >x86_hvm.restore.attempted_1g)) 
> {
> +order = SUPERPAGE_1GB_SHIFT;
> +count = 1UL << order;
> +base_pfn = (pfn >> order) << order;
> +extnt = base_pfn;
> +done = xc_domain_populate_physmap(xch, ctx->domid, 1, order, 0, 
> );
> +DPRINTF("1G base_pfn %" PRI_xen_pfn " done %d\n", base_pfn, done);
> +if (done > 0) {
> +struct xc_sr_bitmap *bm = >x86_hvm.restore.attempted_2m;
> +success = true;
> +stat_1g = done;
> +for (i = 0; i < (count >> SUPERPAGE_2MB_SHIFT); i++)
> +xc_sr_set_bit((base_pfn >> SUPERPAGE_2MB_SHIFT) + i, bm);
> +}
> +}
> +
> +if (!xc_sr_test_and_set_bit(idx_2m, >x86_hvm.restore.attempted_2m)) 
> {
> +order = SUPERPAGE_2MB_SHIFT;
> +count = 1UL << order;
> +base_pfn = (pfn >> order) << order;
> +extnt = base_pfn;
> +done = xc_domain_populate_physmap(xch, ctx->domid, 1, order, 0, 
> );
> +DPRINTF("2M base_pfn %" PRI_xen_pfn " done %d\n", base_pfn, done);
> +if (done > 0) {
> +success = true;
> +stat_2m = done;
> +}
> +}
> +if (success == false) {
> +count = 1;
> +extnt = base_pfn = pfn;
> +done = xc_domain_populate_physmap(xch, ctx->domid, count, 0, 0, 
> );
> +if (done > 0) {
> +success = true;
> +stat_4k = count;
> +}

Re: [Xen-devel] [PATCH V2 1/25] VIOMMU: Add vIOMMU helper functions to create, destroy and query capabilities

[Roger Pau Monné]

On Thu, Aug 17, 2017 at 08:22:16PM -0400, Lan Tianyu wrote:
> This patch is to introduct an abstract layer for arch vIOMMU implementation
> to deal with requests from dom0. Arch vIOMMU code needs to provide callback
> to perform create, destroy and query capabilities operation.
> 
> Signed-off-by: Lan Tianyu 
> ---
>  xen/arch/x86/Kconfig |   1 +
>  xen/arch/x86/setup.c |   1 +
>  xen/common/Kconfig   |   3 +
>  xen/common/Makefile  |   1 +
>  xen/common/domain.c  |   3 +
>  xen/common/viommu.c  | 165 
> +++
>  xen/include/xen/sched.h  |   2 +
>  xen/include/xen/viommu.h |  71 
>  8 files changed, 247 insertions(+)
>  create mode 100644 xen/common/viommu.c
>  create mode 100644 xen/include/xen/viommu.h
> 
> diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
> index 30c2769..1f1de96 100644
> --- a/xen/arch/x86/Kconfig
> +++ b/xen/arch/x86/Kconfig
> @@ -23,6 +23,7 @@ config X86
>   select HAS_PDX
>   select NUMA
>   select VGA
> + select VIOMMU
>  
>  config ARCH_DEFCONFIG
>   string
> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
> index db5df69..68f1631 100644
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -1513,6 +1513,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>  early_msi_init();
>  
>  iommu_setup();/* setup iommu if available */
> +viommu_setup();
>  
>  smp_prepare_cpus(max_cpus);
>  
> diff --git a/xen/common/Kconfig b/xen/common/Kconfig
> index dc8e876..2ad2c8d 100644
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -49,6 +49,9 @@ config HAS_CHECKPOLICY
>   string
>   option env="XEN_HAS_CHECKPOLICY"
>  
> +config VIOMMU
> + bool
> +
>  config KEXEC
>   bool "kexec support"
>   default y
> diff --git a/xen/common/Makefile b/xen/common/Makefile
> index 26c5a64..852553d 100644
> --- a/xen/common/Makefile
> +++ b/xen/common/Makefile
> @@ -56,6 +56,7 @@ obj-y += time.o
>  obj-y += timer.o
>  obj-y += trace.o
>  obj-y += version.o
> +obj-$(CONFIG_VIOMMU) += viommu.o
>  obj-y += virtual_region.o
>  obj-y += vm_event.o
>  obj-y += vmap.o
> diff --git a/xen/common/domain.c b/xen/common/domain.c
> index b22aacc..d1f9b10 100644
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -396,6 +396,9 @@ struct domain *domain_create(domid_t domid, unsigned int 
> domcr_flags,
>  spin_unlock(_update_lock);
>  }
>  
> +if ( (err = viommu_init_domain(d)) != 0 )
> +goto fail;
> +
>  return d;
>  
>   fail:
> diff --git a/xen/common/viommu.c b/xen/common/viommu.c
> new file mode 100644
> index 000..6874d9f
> --- /dev/null
> +++ b/xen/common/viommu.c
> @@ -0,0 +1,165 @@
> +/*
> + * common/viommu.c
> + * 
> + * Copyright (c) 2017 Intel Corporation
> + * Author: Lan Tianyu  
> + *
> + * 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 
> +
> +bool __read_mostly opt_viommu;
> +boolean_param("viommu", opt_viommu);
> +
> +static spinlock_t type_list_lock;

static DEFINE_SPINLOCK(type_list_lock);

> +static struct list_head type_list;

static LIST_HEAD(type_list);

> +
> +struct viommu_type {
> +u64 type;
> +struct viommu_ops *ops;
> +struct list_head node;
> +};
> +
> +int viommu_init_domain(struct domain *d)
> +{
> +d->viommu.nr_viommu = 0;
> +return 0;
> +}

If you don't use the viommu_info struct you can also get rid of this.
The array entries will point to NULL which can be used to signal not
initialized.

> +
> +static struct viommu_type *viommu_get_type(u64 type)
> +{
> +struct viommu_type *viommu_type = NULL;
> +
> +spin_lock(_list_lock);
> +list_for_each_entry( viommu_type, _list, node )
> +{
> +if ( viommu_type->type == type )
> +{
> +spin_unlock(_list_lock);
> +return viommu_type;
> +}
> +}
> +spin_unlock(_list_lock);
> +
> +return NULL;
> +}
> +
> +int viommu_register_type(u64 type, struct viommu_ops * ops)
> +{
> +struct viommu_type *viommu_type = NULL;
> +
> +if ( !viommu_enabled() )
> +return -EINVAL;

ENODEV is maybe better here.

> +
> +if ( viommu_get_type(type) )
> +return -EEXIST;
> +
> +viommu_type = xzalloc(struct viommu_type);
> +if ( !viommu_type )
> +return 

[Xen-devel] [PATCH v2 REPOST 12/12] x86/hvm/ioreq: add a new mappable resource type...

[Paul Durrant]

... XENMEM_resource_ioreq_server

This patch adds support for a new resource type that can be mapped using
the XENMEM_acquire_resource memory op.

If an emulator makes use of this resource type then, instead of mapping
gfns, the IOREQ server will allocate pages from the heap. These pages
will never be present in the P2M of the guest at any point and so are
not vulnerable to any direct attack by the guest. They are only ever
accessible by Xen and any domain that has mapping privilege over the
guest (which may or may not be limited to the domain running the emulator).

NOTE: Use of the new resource type is not compatible with use of
  XEN_DMOP_get_ioreq_server_info unless the XEN_DMOP_no_gfns flag is
  set.

Signed-off-by: Paul Durrant 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
 xen/arch/x86/hvm/ioreq.c| 136 
 xen/arch/x86/mm.c   |  27 
 xen/include/asm-x86/hvm/ioreq.h |   2 +
 xen/include/public/hvm/dm_op.h  |   4 ++
 xen/include/public/memory.h |   3 +
 5 files changed, 172 insertions(+)

diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index 795c198f95..9e6838dab6 100644
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -231,6 +231,15 @@ static int hvm_map_ioreq_gfn(struct hvm_ioreq_server *s, 
bool buf)
 struct hvm_ioreq_page *iorp = buf ? >bufioreq : >ioreq;
 int rc;
 
+if ( iorp->page )
+{
+/* Make sure the page has not been allocated */
+if ( gfn_eq(iorp->gfn, INVALID_GFN) )
+return -EPERM;
+
+return 0;
+}
+
 if ( d->is_dying )
 return -EINVAL;
 
@@ -253,6 +262,60 @@ static int hvm_map_ioreq_gfn(struct hvm_ioreq_server *s, 
bool buf)
 return rc;
 }
 
+static int hvm_alloc_ioreq_mfn(struct hvm_ioreq_server *s, bool buf)
+{
+struct domain *currd = current->domain;
+struct hvm_ioreq_page *iorp = buf ? >bufioreq : >ioreq;
+
+if ( iorp->page )
+{
+/* Make sure the page has not been mapped */
+if ( !gfn_eq(iorp->gfn, INVALID_GFN) )
+return -EPERM;
+
+return 0;
+}
+
+/*
+ * Allocated IOREQ server pages are assigned to the emulating
+ * domain, not the target domain. This is because the emulator is
+ * likely to be destroyed after the target domain has been torn
+ * down, and we must use MEMF_no_refcount otherwise page allocation
+ * could fail if the emulating domain has already reached its
+ * maximum allocation.
+ */
+iorp->page = alloc_domheap_page(currd, MEMF_no_refcount);
+if ( !iorp->page )
+return -ENOMEM;
+
+get_page(iorp->page, currd);
+
+iorp->va = __map_domain_page_global(iorp->page);
+if ( !iorp->va )
+{
+put_page(iorp->page);
+iorp->page = NULL;
+return -ENOMEM;
+}
+
+clear_page(iorp->va);
+return 0;
+}
+
+static void hvm_free_ioreq_mfn(struct hvm_ioreq_server *s, bool buf)
+{
+struct hvm_ioreq_page *iorp = buf ? >bufioreq : >ioreq;
+
+if ( !iorp->page )
+return;
+
+unmap_domain_page_global(iorp->va);
+iorp->va = NULL;
+
+put_page(iorp->page);
+iorp->page = NULL;
+}
+
 bool is_ioreq_server_page(struct domain *d, const struct page_info *page)
 {
 const struct hvm_ioreq_server *s;
@@ -457,6 +520,27 @@ static void hvm_ioreq_server_unmap_pages(struct 
hvm_ioreq_server *s)
 hvm_unmap_ioreq_gfn(s, false);
 }
 
+static int hvm_ioreq_server_alloc_pages(struct hvm_ioreq_server *s)
+{
+int rc = -ENOMEM;
+
+rc = hvm_alloc_ioreq_mfn(s, false);
+
+if ( !rc && (s->bufioreq_handling != HVM_IOREQSRV_BUFIOREQ_OFF) )
+rc = hvm_alloc_ioreq_mfn(s, true);
+
+if ( rc )
+hvm_free_ioreq_mfn(s, false);
+
+return rc;
+}
+
+static void hvm_ioreq_server_free_pages(struct hvm_ioreq_server *s)
+{
+hvm_free_ioreq_mfn(s, true);
+hvm_free_ioreq_mfn(s, false);
+}
+
 static void hvm_ioreq_server_free_rangesets(struct hvm_ioreq_server *s)
 {
 unsigned int i;
@@ -583,7 +667,18 @@ static int hvm_ioreq_server_init(struct hvm_ioreq_server 
*s,
 
  fail_add:
 hvm_ioreq_server_remove_all_vcpus(s);
+
+/*
+ * NOTE: It is safe to call both hvm_ioreq_server_unmap_pages() and
+ *   hvm_ioreq_server_free_pages() in that order.
+ *   This is because the former will do nothing if the pages
+ *   are not mapped, leaving the page to be freed by the latter.
+ *   However if the pages are mapped then the former will set
+ *   the page_info pointer to NULL, meaning the latter will do
+ *   nothing.
+ */
 hvm_ioreq_server_unmap_pages(s);
+

[Xen-devel] [PATCH v2 REPOST 11/12] x86/hvm/ioreq: defer mapping gfns until they are actually requsted

[Paul Durrant]

A subsequent patch will introduce a new scheme to allow an emulator to
map IOREQ server pages directly from Xen rather than the guest P2M.

This patch lays the groundwork for that change by deferring mapping of
gfns until their values are requested by an emulator. To that end, the
pad field of the xen_dm_op_get_ioreq_server_info structure is re-purposed
to a flags field and new flag, XEN_DMOP_no_gfns, defined which modifies the
behaviour of XEN_DMOP_get_ioreq_server_info to allow the caller to avoid
requesting the gfn values.

Signed-off-by: Paul Durrant 
---
Cc: Ian Jackson 
Cc: Wei Liu 
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
---
 tools/libs/devicemodel/core.c   |  8 +
 tools/libs/devicemodel/include/xendevicemodel.h |  6 ++--
 xen/arch/x86/hvm/dm.c   |  9 +++--
 xen/arch/x86/hvm/ioreq.c| 44 ++---
 xen/include/asm-x86/hvm/domain.h|  2 +-
 xen/include/public/hvm/dm_op.h  | 32 ++
 6 files changed, 61 insertions(+), 40 deletions(-)

diff --git a/tools/libs/devicemodel/core.c b/tools/libs/devicemodel/core.c
index fcb260d29b..907c894e77 100644
--- a/tools/libs/devicemodel/core.c
+++ b/tools/libs/devicemodel/core.c
@@ -188,6 +188,14 @@ int xendevicemodel_get_ioreq_server_info(
 
 data->id = id;
 
+/*
+ * If the caller is not requesting gfn values then instruct the
+ * hypercall not to retrieve them as this may cause them to be
+ * mapped.
+ */
+if (!ioreq_gfn && !bufioreq_gfn)
+data->flags = XEN_DMOP_no_gfns;
+
 rc = xendevicemodel_op(dmod, domid, 1, , sizeof(op));
 if (rc)
 return rc;
diff --git a/tools/libs/devicemodel/include/xendevicemodel.h 
b/tools/libs/devicemodel/include/xendevicemodel.h
index 13216db04a..da6b253cfd 100644
--- a/tools/libs/devicemodel/include/xendevicemodel.h
+++ b/tools/libs/devicemodel/include/xendevicemodel.h
@@ -61,11 +61,11 @@ int xendevicemodel_create_ioreq_server(
  * @parm domid the domain id to be serviced
  * @parm id the IOREQ Server id.
  * @parm ioreq_gfn pointer to a xen_pfn_t to receive the synchronous ioreq
- *  gfn
+ *  gmfn. (May be NULL if not required)
  * @parm bufioreq_gfn pointer to a xen_pfn_t to receive the buffered ioreq
- *gfn
+ *gmfn. (May be NULL if not required)
  * @parm bufioreq_port pointer to a evtchn_port_t to receive the buffered
- * ioreq event channel
+ * ioreq event channel. (May be NULL if not required)
  * @return 0 on success, -1 on failure.
  */
 int xendevicemodel_get_ioreq_server_info(
diff --git a/xen/arch/x86/hvm/dm.c b/xen/arch/x86/hvm/dm.c
index 87ef4b6ca9..c020f0c99f 100644
--- a/xen/arch/x86/hvm/dm.c
+++ b/xen/arch/x86/hvm/dm.c
@@ -418,16 +418,19 @@ static int dm_op(const struct dmop_args *op_args)
 {
 struct xen_dm_op_get_ioreq_server_info *data =
 _ioreq_server_info;
+const uint16_t valid_flags = XEN_DMOP_no_gfns;
 
 const_op = false;
 
 rc = -EINVAL;
-if ( data->pad )
+if ( data->flags & ~valid_flags )
 break;
 
 rc = hvm_get_ioreq_server_info(d, data->id,
-   >ioreq_gfn,
-   >bufioreq_gfn,
+   (data->flags & XEN_DMOP_no_gfns) ?
+   NULL : >ioreq_gfn,
+   (data->flags & XEN_DMOP_no_gfns) ?
+   NULL : >bufioreq_gfn,
>bufioreq_port);
 break;
 }
diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index 3a9aaf1f5d..795c198f95 100644
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -344,7 +344,8 @@ static int hvm_ioreq_server_add_vcpu(struct 
hvm_ioreq_server *s,
 
 sv->ioreq_evtchn = rc;
 
-if ( v->vcpu_id == 0 && s->bufioreq.va != NULL )
+if ( v->vcpu_id == 0 &&
+ (s->bufioreq_handling != HVM_IOREQSRV_BUFIOREQ_OFF) )
 {
 struct domain *d = s->domain;
 
@@ -395,7 +396,8 @@ static void hvm_ioreq_server_remove_vcpu(struct 
hvm_ioreq_server *s,
 
 list_del(>list_entry);
 
-if ( v->vcpu_id == 0 && s->bufioreq.va != NULL )
+if ( v->vcpu_id == 0 &&
+ (s->bufioreq_handling != HVM_IOREQSRV_BUFIOREQ_OFF) )
 free_xen_event_channel(v->domain, s->bufioreq_evtchn);
 
 free_xen_event_channel(v->domain, sv->ioreq_evtchn);
@@ -422,7 +424,8 @@ static void hvm_ioreq_server_remove_all_vcpus(struct 

[Xen-devel] [PATCH v2 REPOST 10/12] x86/hvm/ioreq: use gfn_t in struct hvm_ioreq_page

[Paul Durrant]

This patch adjusts the IOREQ server code to use type-safe gfn_t values
where possible. No functional change.

Signed-off-by: Paul Durrant 
---
Cc: Andrew Cooper 
Cc: Jan Beulich 
---
 xen/arch/x86/hvm/ioreq.c | 42 
 xen/include/asm-x86/hvm/domain.h |  2 +-
 2 files changed, 22 insertions(+), 22 deletions(-)

diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index edfb394c59..3a9aaf1f5d 100644
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -181,7 +181,7 @@ bool handle_hvm_io_completion(struct vcpu *v)
 return true;
 }
 
-static unsigned long hvm_alloc_ioreq_gfn(struct hvm_ioreq_server *s)
+static gfn_t hvm_alloc_ioreq_gfn(struct hvm_ioreq_server *s)
 {
 struct domain *d = s->domain;
 unsigned int i;
@@ -192,18 +192,17 @@ static unsigned long hvm_alloc_ioreq_gfn(struct 
hvm_ioreq_server *s)
 {
 if ( test_and_clear_bit(i, >arch.hvm_domain.ioreq_gfn.mask) )
 {
-return d->arch.hvm_domain.ioreq_gfn.base + i;
+return _gfn(d->arch.hvm_domain.ioreq_gfn.base + i);
 }
 }
 
-return gfn_x(INVALID_GFN);
+return INVALID_GFN;
 }
 
-static void hvm_free_ioreq_gfn(struct hvm_ioreq_server *s,
-   unsigned long gfn)
+static void hvm_free_ioreq_gfn(struct hvm_ioreq_server *s, gfn_t gfn)
 {
 struct domain *d = s->domain;
-unsigned int i = gfn - d->arch.hvm_domain.ioreq_gfn.base;
+unsigned int i = gfn_x(gfn) - d->arch.hvm_domain.ioreq_gfn.base;
 
 ASSERT(!s->is_default);
 
@@ -214,7 +213,7 @@ static void hvm_unmap_ioreq_gfn(struct hvm_ioreq_server *s, 
bool buf)
 {
 struct hvm_ioreq_page *iorp = buf ? >bufioreq : >ioreq;
 
-if ( iorp->gfn == gfn_x(INVALID_GFN) )
+if ( gfn_eq(iorp->gfn, INVALID_GFN) )
 return;
 
 destroy_ring_for_helper(>va, iorp->page);
@@ -223,7 +222,7 @@ static void hvm_unmap_ioreq_gfn(struct hvm_ioreq_server *s, 
bool buf)
 if ( !s->is_default )
 hvm_free_ioreq_gfn(s, iorp->gfn);
 
-iorp->gfn = gfn_x(INVALID_GFN);
+iorp->gfn = INVALID_GFN;
 }
 
 static int hvm_map_ioreq_gfn(struct hvm_ioreq_server *s, bool buf)
@@ -236,16 +235,17 @@ static int hvm_map_ioreq_gfn(struct hvm_ioreq_server *s, 
bool buf)
 return -EINVAL;
 
 if ( s->is_default )
-iorp->gfn = buf ?
-d->arch.hvm_domain.params[HVM_PARAM_BUFIOREQ_PFN] :
-d->arch.hvm_domain.params[HVM_PARAM_IOREQ_PFN];
+iorp->gfn = _gfn(buf ?
+ d->arch.hvm_domain.params[HVM_PARAM_BUFIOREQ_PFN] :
+ d->arch.hvm_domain.params[HVM_PARAM_IOREQ_PFN]);
 else
 iorp->gfn = hvm_alloc_ioreq_gfn(s);
 
-if ( iorp->gfn == gfn_x(INVALID_GFN) )
+if ( gfn_eq(iorp->gfn, INVALID_GFN) )
 return -ENOMEM;
 
-rc = prepare_ring_for_helper(d, iorp->gfn, >page, >va);
+rc = prepare_ring_for_helper(d, gfn_x(iorp->gfn), >page,
+ >va);
 
 if ( rc )
 hvm_unmap_ioreq_gfn(s, buf);
@@ -282,10 +282,10 @@ static void hvm_remove_ioreq_gfn(struct hvm_ioreq_server 
*s, bool buf)
 struct domain *d = s->domain;
 struct hvm_ioreq_page *iorp = buf ? >bufioreq : >ioreq;
 
-if ( s->is_default || iorp->gfn == gfn_x(INVALID_GFN) )
+if ( s->is_default || gfn_eq(iorp->gfn, INVALID_GFN) )
 return;
 
-if ( guest_physmap_remove_page(d, _gfn(iorp->gfn),
+if ( guest_physmap_remove_page(d, iorp->gfn,
_mfn(page_to_mfn(iorp->page)), 0) )
 domain_crash(d);
 clear_page(iorp->va);
@@ -297,12 +297,12 @@ static int hvm_add_ioreq_gfn(struct hvm_ioreq_server *s, 
bool buf)
 struct hvm_ioreq_page *iorp = buf ? >bufioreq : >ioreq;
 int rc;
 
-if ( s->is_default || iorp->gfn == gfn_x(INVALID_GFN) )
+if ( s->is_default || gfn_eq(iorp->gfn, INVALID_GFN) )
 return 0;
 
 clear_page(iorp->va);
 
-rc = guest_physmap_add_page(d, _gfn(iorp->gfn),
+rc = guest_physmap_add_page(d, iorp->gfn,
 _mfn(page_to_mfn(iorp->page)), 0);
 if ( rc == 0 )
 paging_mark_dirty(d, _mfn(page_to_mfn(iorp->page)));
@@ -561,8 +561,8 @@ static int hvm_ioreq_server_init(struct hvm_ioreq_server *s,
 INIT_LIST_HEAD(>ioreq_vcpu_list);
 spin_lock_init(>bufioreq_lock);
 
-s->ioreq.gfn = gfn_x(INVALID_GFN);
-s->bufioreq.gfn = gfn_x(INVALID_GFN);
+s->ioreq.gfn = INVALID_GFN;
+s->bufioreq.gfn = INVALID_GFN;
 
 rc = hvm_ioreq_server_alloc_rangesets(s);
 if ( rc )
@@ -747,11 +747,11 @@ int hvm_get_ioreq_server_info(struct domain *d, 
ioservid_t id,
 if ( s->id != id )
 continue;
 
-*ioreq_gfn = s->ioreq.gfn;
+*ioreq_gfn = gfn_x(s->ioreq.gfn);
 
 if ( s->bufioreq.va != NULL )
 {
-*bufioreq_gfn = s->bufioreq.gfn;
+

Re: [Xen-devel] [PATCH v2 2/3] tools/libxc: add API for bitmap access for restore

[Wei Liu]

On Tue, Aug 22, 2017 at 03:34:37PM +0100, Wei Liu wrote:
> > +static inline int pfn_set_populated(struct xc_sr_context *ctx, xen_pfn_t 
> > pfn)
> > +{
> > +xc_interface *xch = ctx->xch;
> > +
> 
> This is not used, right?

Oh this is acutally used. Please ignore this comment.

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

[Xen-devel] [PATCH v2 REPOST 08/12] x86/hvm/ioreq: move is_default into struct hvm_ioreq_server

[Paul Durrant]

Legacy emulators use the 'default' IOREQ server which has slightly
different semantics than other, explicitly created, IOREQ servers.

Because of this, most of the initialization and teardown code needs to
know whether the server is default or not. This is currently achieved
by passing an is_default boolean argument to the functions in question,
whereas this argument could be avoided by adding a field to the
hvm_ioreq_server structure which is also passed as an argument to all
the relevant functions.

Signed-off-by: Paul Durrant 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/x86/hvm/ioreq.c | 80 ++--
 xen/include/asm-x86/hvm/domain.h |  1 +
 2 files changed, 36 insertions(+), 45 deletions(-)

diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index 5e01e1a6d2..5737082238 100644
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -302,7 +302,7 @@ static void hvm_update_ioreq_evtchn(struct hvm_ioreq_server 
*s,
 }
 
 static int hvm_ioreq_server_add_vcpu(struct hvm_ioreq_server *s,
- bool is_default, struct vcpu *v)
+ struct vcpu *v)
 {
 struct hvm_ioreq_vcpu *sv;
 int rc;
@@ -331,7 +331,7 @@ static int hvm_ioreq_server_add_vcpu(struct 
hvm_ioreq_server *s,
 goto fail3;
 
 s->bufioreq_evtchn = rc;
-if ( is_default )
+if ( s->is_default )
 d->arch.hvm_domain.params[HVM_PARAM_BUFIOREQ_EVTCHN] =
 s->bufioreq_evtchn;
 }
@@ -431,7 +431,6 @@ static int hvm_ioreq_server_map_pages(struct 
hvm_ioreq_server *s,
 }
 
 static int hvm_ioreq_server_setup_pages(struct hvm_ioreq_server *s,
-bool is_default,
 bool handle_bufioreq)
 {
 struct domain *d = s->domain;
@@ -439,7 +438,7 @@ static int hvm_ioreq_server_setup_pages(struct 
hvm_ioreq_server *s,
 unsigned long bufioreq_gfn = gfn_x(INVALID_GFN);
 int rc;
 
-if ( is_default )
+if ( s->is_default )
 {
 /*
  * The default ioreq server must handle buffered ioreqs, for
@@ -468,8 +467,7 @@ static int hvm_ioreq_server_setup_pages(struct 
hvm_ioreq_server *s,
 return rc;
 }
 
-static void hvm_ioreq_server_unmap_pages(struct hvm_ioreq_server *s,
- bool is_default)
+static void hvm_ioreq_server_unmap_pages(struct hvm_ioreq_server *s)
 {
 struct domain *d = s->domain;
 bool handle_bufioreq = !!s->bufioreq.va;
@@ -479,7 +477,7 @@ static void hvm_ioreq_server_unmap_pages(struct 
hvm_ioreq_server *s,
 
 hvm_unmap_ioreq_page(s, false);
 
-if ( !is_default )
+if ( !s->is_default )
 {
 if ( handle_bufioreq )
 hvm_free_ioreq_gfn(d, s->bufioreq.gfn);
@@ -488,25 +486,23 @@ static void hvm_ioreq_server_unmap_pages(struct 
hvm_ioreq_server *s,
 }
 }
 
-static void hvm_ioreq_server_free_rangesets(struct hvm_ioreq_server *s,
-bool is_default)
+static void hvm_ioreq_server_free_rangesets(struct hvm_ioreq_server *s)
 {
 unsigned int i;
 
-if ( is_default )
+if ( s->is_default )
 return;
 
 for ( i = 0; i < NR_IO_RANGE_TYPES; i++ )
 rangeset_destroy(s->range[i]);
 }
 
-static int hvm_ioreq_server_alloc_rangesets(struct hvm_ioreq_server *s,
-bool is_default)
+static int hvm_ioreq_server_alloc_rangesets(struct hvm_ioreq_server *s)
 {
 unsigned int i;
 int rc;
 
-if ( is_default )
+if ( s->is_default )
 goto done;
 
 for ( i = 0; i < NR_IO_RANGE_TYPES; i++ )
@@ -537,13 +533,12 @@ static int hvm_ioreq_server_alloc_rangesets(struct 
hvm_ioreq_server *s,
 return 0;
 
  fail:
-hvm_ioreq_server_free_rangesets(s, false);
+hvm_ioreq_server_free_rangesets(s);
 
 return rc;
 }
 
-static void hvm_ioreq_server_enable(struct hvm_ioreq_server *s,
-bool is_default)
+static void hvm_ioreq_server_enable(struct hvm_ioreq_server *s)
 {
 struct domain *d = s->domain;
 struct hvm_ioreq_vcpu *sv;
@@ -554,7 +549,7 @@ static void hvm_ioreq_server_enable(struct hvm_ioreq_server 
*s,
 if ( s->enabled )
 goto done;
 
-if ( !is_default )
+if ( !s->is_default )
 {
 hvm_remove_ioreq_gfn(d, >ioreq);
 
@@ -573,8 +568,7 @@ static void hvm_ioreq_server_enable(struct hvm_ioreq_server 
*s,
 spin_unlock(>lock);
 }
 
-static void hvm_ioreq_server_disable(struct hvm_ioreq_server *s,
- bool is_default)
+static void hvm_ioreq_server_disable(struct hvm_ioreq_server *s)
 {
 struct domain *d = s->domain;
 bool handle_bufioreq = !!s->bufioreq.va;
@@ -584,7 +578,7 @@ static void hvm_ioreq_server_disable(struct 
hvm_ioreq_server *s,
 if ( !s->enabled )
  

[Xen-devel] [PATCH v2 REPOST 01/12] [x86|arm]: remove code duplication

[Paul Durrant]

There is a substantial amount of code duplicated between the x86 and arm
implementations of mm.c:xenmem_add_to_physmap_one() for
XENMAPSPACE_grant_table. Also, the code in question looks like it really
should be in common/grant_table.c

This patch introduces a new function in common/grant_table.c to get the mfn
of a specified frame in the grant table of a specified guest, and calls to
that from the arch-specific code in mm.c.

Signed-off-by: Paul Durrant 
---
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/arm/mm.c | 29 -
 xen/arch/x86/mm.c | 26 +++---
 xen/common/grant_table.c  | 33 +
 xen/include/xen/grant_table.h |  3 +++
 4 files changed, 43 insertions(+), 48 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index a810a056d7..5ae9607821 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -1229,32 +1229,11 @@ int xenmem_add_to_physmap_one(
 switch ( space )
 {
 case XENMAPSPACE_grant_table:
-grant_write_lock(d->grant_table);
-
-if ( d->grant_table->gt_version == 0 )
-d->grant_table->gt_version = 1;
-
-if ( d->grant_table->gt_version == 2 &&
-(idx & XENMAPIDX_grant_table_status) )
-{
-idx &= ~XENMAPIDX_grant_table_status;
-if ( idx < nr_status_frames(d->grant_table) )
-mfn = virt_to_mfn(d->grant_table->status[idx]);
-else
-return -EINVAL;
-}
-else
-{
-if ( (idx >= nr_grant_frames(d->grant_table)) &&
- (idx < max_grant_frames) )
-gnttab_grow_table(d, idx + 1);
-
-if ( idx < nr_grant_frames(d->grant_table) )
-mfn = virt_to_mfn(d->grant_table->shared_raw[idx]);
-else
-return -EINVAL;
-}
+mfn = gnttab_get_frame(d, idx);
+if ( mfn_eq(mfn, INVALID_MFN) )
+return -EINVAL;
 
+grant_write_lock(d->grant_table);
 d->arch.grant_table_gfn[idx] = gfn;
 
 t = p2m_ram_rw;
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 5b863c6fa6..0abb1e284f 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4639,29 +4639,9 @@ int xenmem_add_to_physmap_one(
 mfn = virt_to_mfn(d->shared_info);
 break;
 case XENMAPSPACE_grant_table:
-grant_write_lock(d->grant_table);
-
-if ( d->grant_table->gt_version == 0 )
-d->grant_table->gt_version = 1;
-
-if ( d->grant_table->gt_version == 2 &&
- (idx & XENMAPIDX_grant_table_status) )
-{
-idx &= ~XENMAPIDX_grant_table_status;
-if ( idx < nr_status_frames(d->grant_table) )
-mfn = virt_to_mfn(d->grant_table->status[idx]);
-}
-else
-{
-if ( (idx >= nr_grant_frames(d->grant_table)) &&
- (idx < max_grant_frames) )
-gnttab_grow_table(d, idx + 1);
-
-if ( idx < nr_grant_frames(d->grant_table) )
-mfn = virt_to_mfn(d->grant_table->shared_raw[idx]);
-}
-
-grant_write_unlock(d->grant_table);
+mfn = mfn_x(gnttab_get_frame(d, idx));
+if ( mfn_eq(_mfn(mfn), INVALID_MFN) )
+return -EINVAL;
 break;
 case XENMAPSPACE_gmfn_range:
 case XENMAPSPACE_gmfn:
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index 0f9dd1e706..b327458301 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -1621,6 +1621,39 @@ active_alloc_failed:
 return 0;
 }
 
+mfn_t
+gnttab_get_frame(struct domain *d, unsigned int idx)
+{
+struct grant_table *gt = d->grant_table;
+mfn_t mfn = INVALID_MFN;
+
+grant_write_lock(gt);
+
+if ( gt->gt_version == 0 )
+gt->gt_version = 1;
+
+if ( gt->gt_version == 2 &&
+ (idx & XENMAPIDX_grant_table_status) )
+{
+idx &= ~XENMAPIDX_grant_table_status;
+if ( idx < nr_status_frames(gt) )
+mfn = _mfn(virt_to_mfn(gt->status[idx]));
+}
+else
+{
+if ( (idx >= nr_grant_frames(gt)) &&
+ (idx < max_grant_frames) )
+gnttab_grow_table(d, idx + 1);
+
+if ( idx < nr_grant_frames(gt) )
+mfn = _mfn(virt_to_mfn(gt->shared_raw[idx]));
+}
+
+grant_write_unlock(gt);
+
+return mfn;
+}
+
 static long 
 gnttab_setup_table(
 XEN_GUEST_HANDLE_PARAM(gnttab_setup_table_t) uop, unsigned int count)
diff --git a/xen/include/xen/grant_table.h b/xen/include/xen/grant_table.h
index b5af21b53c..079cf82a1e 100644
--- a/xen/include/xen/grant_table.h
+++ 

[Xen-devel] [PATCH v2 REPOST 04/12] tools/libxenforeignmemory: add support for resource mapping

[Paul Durrant]

A previous patch introduced a new HYPERVISOR_memory_op to acquire guest
resources for direct priv-mapping.

This patch adds new functionality into libxenforeignmemory to make use
of a new privcmd ioctl [1] that uses the new memory op to make such
resources available via mmap(2).

[1] 
http://xenbits.xen.org/gitweb/?p=people/pauldu/linux.git;a=commit;h=ce59a05e6712

Signed-off-by: Paul Durrant 
---
Cc: Ian Jackson 
Cc: Wei Liu 

v2:
 - Bump minor version up to 3
---
 tools/include/xen-sys/Linux/privcmd.h  | 11 ++
 tools/libs/foreignmemory/Makefile  |  2 +-
 tools/libs/foreignmemory/core.c| 42 
 .../libs/foreignmemory/include/xenforeignmemory.h  | 39 +++
 tools/libs/foreignmemory/libxenforeignmemory.map   |  5 +++
 tools/libs/foreignmemory/linux.c   | 45 ++
 tools/libs/foreignmemory/private.h | 30 +++
 7 files changed, 173 insertions(+), 1 deletion(-)

diff --git a/tools/include/xen-sys/Linux/privcmd.h 
b/tools/include/xen-sys/Linux/privcmd.h
index 732ff7c15a..9531b728f9 100644
--- a/tools/include/xen-sys/Linux/privcmd.h
+++ b/tools/include/xen-sys/Linux/privcmd.h
@@ -86,6 +86,15 @@ typedef struct privcmd_dm_op {
const privcmd_dm_op_buf_t __user *ubufs;
 } privcmd_dm_op_t;
 
+typedef struct privcmd_mmap_resource {
+   domid_t dom;
+   __u32 type;
+   __u32 id;
+   __u32 idx;
+   __u64 num;
+   __u64 addr;
+} privcmd_mmap_resource_t;
+
 /*
  * @cmd: IOCTL_PRIVCMD_HYPERCALL
  * @arg: _hypercall_t
@@ -103,5 +112,7 @@ typedef struct privcmd_dm_op {
_IOC(_IOC_NONE, 'P', 5, sizeof(privcmd_dm_op_t))
 #define IOCTL_PRIVCMD_RESTRICT \
_IOC(_IOC_NONE, 'P', 6, sizeof(domid_t))
+#define IOCTL_PRIVCMD_MMAP_RESOURCE\
+   _IOC(_IOC_NONE, 'P', 7, sizeof(privcmd_mmap_resource_t))
 
 #endif /* __LINUX_PUBLIC_PRIVCMD_H__ */
diff --git a/tools/libs/foreignmemory/Makefile 
b/tools/libs/foreignmemory/Makefile
index b110076621..7eb59c78cb 100644
--- a/tools/libs/foreignmemory/Makefile
+++ b/tools/libs/foreignmemory/Makefile
@@ -2,7 +2,7 @@ XEN_ROOT = $(CURDIR)/../../..
 include $(XEN_ROOT)/tools/Rules.mk
 
 MAJOR= 1
-MINOR= 2
+MINOR= 3
 SHLIB_LDFLAGS += -Wl,--version-script=libxenforeignmemory.map
 
 CFLAGS   += -Werror -Wmissing-prototypes
diff --git a/tools/libs/foreignmemory/core.c b/tools/libs/foreignmemory/core.c
index a6897dc561..291ee44516 100644
--- a/tools/libs/foreignmemory/core.c
+++ b/tools/libs/foreignmemory/core.c
@@ -120,6 +120,48 @@ int xenforeignmemory_restrict(xenforeignmemory_handle 
*fmem,
 return osdep_xenforeignmemory_restrict(fmem, domid);
 }
 
+xenforeignmemory_resource_handle *xenforeignmemory_map_resource(
+xenforeignmemory_handle *fmem, domid_t domid, unsigned int type,
+unsigned int id, unsigned long frame, unsigned long nr_frames,
+void **paddr, int prot, int flags)
+{
+xenforeignmemory_resource_handle *fres;
+int rc;
+
+fres = calloc(1, sizeof(*fres));
+if ( !fres )
+return NULL;
+
+fres->domid = domid;
+fres->type = type;
+fres->id = id;
+fres->frame = frame;
+fres->nr_frames = nr_frames;
+fres->addr = *paddr;
+fres->prot = prot;
+fres->flags = flags;
+
+rc = osdep_xenforeignmemory_map_resource(fmem, fres);
+if ( rc )
+goto fail;
+
+*paddr = fres->addr;
+return fres;
+
+fail:
+free(fres);
+
+return NULL;
+}
+
+void xenforeignmemory_unmap_resource(
+xenforeignmemory_handle *fmem, xenforeignmemory_resource_handle *fres)
+{
+osdep_xenforeignmemory_unmap_resource(fmem, fres);
+
+free(fres);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libs/foreignmemory/include/xenforeignmemory.h 
b/tools/libs/foreignmemory/include/xenforeignmemory.h
index f4814c390f..e56eb3c4d4 100644
--- a/tools/libs/foreignmemory/include/xenforeignmemory.h
+++ b/tools/libs/foreignmemory/include/xenforeignmemory.h
@@ -138,6 +138,45 @@ int xenforeignmemory_unmap(xenforeignmemory_handle *fmem,
 int xenforeignmemory_restrict(xenforeignmemory_handle *fmem,
   domid_t domid);
 
+typedef struct xenforeignmemory_resource_handle 
xenforeignmemory_resource_handle;
+
+/**
+ * This function maps a guest resource.
+ *
+ * @parm fmem handle to the open foreignmemory interface
+ * @parm domid the domain id
+ * @parm type the resource type
+ * @parm id the type-specific resource identifier
+ * @parm frame base frame index within the resource
+ * @parm nr_frames number of frames to map
+ * @parm paddr pointer to an address passed through to mmap(2)
+ * @parm prot passed through to mmap(2)
+ * @parm flags passed through to mmap(2)
+ * @return pointer to foreignmemory resource handle on success, NULL on
+ * failure
+ *
+ * *paddr is used, on 

[Xen-devel] [PATCH v2 REPOST 09/12] x86/hvm/ioreq: simplify code and use consistent naming

[Paul Durrant]

This patch re-works much of the IOREQ server initialization and teardown
code:

- The hvm_map/unmap_ioreq_gfn() functions are expanded to call through
  to hvm_alloc/free_ioreq_gfn() rather than expecting them to be called
  separately by outer functions.
- Several functions now test the validity of the hvm_ioreq_page gfn value
  to determine whether they need to act. This means can be safely called
  for the bufioreq page even when it is not used.
- hvm_add/remove_ioreq_gfn() simply return in the case of the default
  IOREQ server so callers no longer need to test before calling.
- hvm_ioreq_server_setup_pages() is renamed to hvm_ioreq_server_map_pages()
  to mirror the existing hvm_ioreq_server_unmap_pages().

All of this significantly shortens the code.

Signed-off-by: Paul Durrant 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/x86/hvm/ioreq.c | 181 ++-
 1 file changed, 69 insertions(+), 112 deletions(-)

diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index 5737082238..edfb394c59 100644
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -181,63 +181,76 @@ bool handle_hvm_io_completion(struct vcpu *v)
 return true;
 }
 
-static int hvm_alloc_ioreq_gfn(struct domain *d, unsigned long *gfn)
+static unsigned long hvm_alloc_ioreq_gfn(struct hvm_ioreq_server *s)
 {
+struct domain *d = s->domain;
 unsigned int i;
-int rc;
 
-rc = -ENOMEM;
+ASSERT(!s->is_default);
+
 for ( i = 0; i < sizeof(d->arch.hvm_domain.ioreq_gfn.mask) * 8; i++ )
 {
 if ( test_and_clear_bit(i, >arch.hvm_domain.ioreq_gfn.mask) )
 {
-*gfn = d->arch.hvm_domain.ioreq_gfn.base + i;
-rc = 0;
-break;
+return d->arch.hvm_domain.ioreq_gfn.base + i;
 }
 }
 
-return rc;
+return gfn_x(INVALID_GFN);
 }
 
-static void hvm_free_ioreq_gfn(struct domain *d, unsigned long gfn)
+static void hvm_free_ioreq_gfn(struct hvm_ioreq_server *s,
+   unsigned long gfn)
 {
+struct domain *d = s->domain;
 unsigned int i = gfn - d->arch.hvm_domain.ioreq_gfn.base;
 
-if ( gfn != gfn_x(INVALID_GFN) )
-set_bit(i, >arch.hvm_domain.ioreq_gfn.mask);
+ASSERT(!s->is_default);
+
+set_bit(i, >arch.hvm_domain.ioreq_gfn.mask);
 }
 
-static void hvm_unmap_ioreq_page(struct hvm_ioreq_server *s, bool buf)
+static void hvm_unmap_ioreq_gfn(struct hvm_ioreq_server *s, bool buf)
 {
 struct hvm_ioreq_page *iorp = buf ? >bufioreq : >ioreq;
 
+if ( iorp->gfn == gfn_x(INVALID_GFN) )
+return;
+
 destroy_ring_for_helper(>va, iorp->page);
+iorp->page = NULL;
+
+if ( !s->is_default )
+hvm_free_ioreq_gfn(s, iorp->gfn);
+
+iorp->gfn = gfn_x(INVALID_GFN);
 }
 
-static int hvm_map_ioreq_page(
-struct hvm_ioreq_server *s, bool buf, unsigned long gfn)
+static int hvm_map_ioreq_gfn(struct hvm_ioreq_server *s, bool buf)
 {
 struct domain *d = s->domain;
 struct hvm_ioreq_page *iorp = buf ? >bufioreq : >ioreq;
-struct page_info *page;
-void *va;
 int rc;
 
-if ( (rc = prepare_ring_for_helper(d, gfn, , )) )
-return rc;
-
-if ( (iorp->va != NULL) || d->is_dying )
-{
-destroy_ring_for_helper(, page);
+if ( d->is_dying )
 return -EINVAL;
-}
 
-iorp->va = va;
-iorp->page = page;
-iorp->gfn = gfn;
+if ( s->is_default )
+iorp->gfn = buf ?
+d->arch.hvm_domain.params[HVM_PARAM_BUFIOREQ_PFN] :
+d->arch.hvm_domain.params[HVM_PARAM_IOREQ_PFN];
+else
+iorp->gfn = hvm_alloc_ioreq_gfn(s);
+
+if ( iorp->gfn == gfn_x(INVALID_GFN) )
+return -ENOMEM;
 
-return 0;
+rc = prepare_ring_for_helper(d, iorp->gfn, >page, >va);
+
+if ( rc )
+hvm_unmap_ioreq_gfn(s, buf);
+
+return rc;
 }
 
 bool is_ioreq_server_page(struct domain *d, const struct page_info *page)
@@ -251,8 +264,7 @@ bool is_ioreq_server_page(struct domain *d, const struct 
page_info *page)
   >arch.hvm_domain.ioreq_server.list,
   list_entry )
 {
-if ( (s->ioreq.va && s->ioreq.page == page) ||
- (s->bufioreq.va && s->bufioreq.page == page) )
+if ( (s->ioreq.page == page) || (s->bufioreq.page == page) )
 {
 found = true;
 break;
@@ -264,20 +276,30 @@ bool is_ioreq_server_page(struct domain *d, const struct 
page_info *page)
 return found;
 }
 
-static void hvm_remove_ioreq_gfn(
-struct domain *d, struct hvm_ioreq_page *iorp)
+static void hvm_remove_ioreq_gfn(struct hvm_ioreq_server *s, bool buf)
+
 {
+struct domain *d = s->domain;
+struct hvm_ioreq_page *iorp = buf ? >bufioreq : >ioreq;
+
+if ( s->is_default || iorp->gfn == gfn_x(INVALID_GFN) )
+return;
+
 if ( guest_physmap_remove_page(d, 

[Xen-devel] [PATCH v2 REPOST 00/12] x86: guest resource mapping

[Paul Durrant]

(REPOST after rebase and reference fix in patch #4 comment)

This series introduces support for direct mapping of guest resources.
The resources are:
 - Grant tables
 - IOREQ server pages

Paul Durrant (12):
  [x86|arm]: remove code duplication
  x86/mm: allow a privileged PV domain to map guest mfns
  x86/mm: add HYPERVISOR_memory_op to acquire guest resources
  tools/libxenforeignmemory: add support for resource mapping
  tools/libxenctrl: use new xenforeignmemory API to seed grant table
  x86/hvm/ioreq: rename .*pfn and .*gmfn to .*gfn
  x86/hvm/ioreq: use bool rather than bool_t
  x86/hvm/ioreq: move is_default into struct hvm_ioreq_server
  x86/hvm/ioreq: simplify code and use consistent naming
  x86/hvm/ioreq: use gfn_t in struct hvm_ioreq_page
  x86/hvm/ioreq: defer mapping gfns until they are actually requsted
  x86/hvm/ioreq: add a new mappable resource type...

 tools/include/xen-sys/Linux/privcmd.h  |  11 +
 tools/libs/devicemodel/core.c  |  18 +-
 tools/libs/devicemodel/include/xendevicemodel.h|  14 +-
 tools/libs/foreignmemory/Makefile  |   2 +-
 tools/libs/foreignmemory/core.c|  42 ++
 .../libs/foreignmemory/include/xenforeignmemory.h  |  39 ++
 tools/libs/foreignmemory/libxenforeignmemory.map   |   5 +
 tools/libs/foreignmemory/linux.c   |  45 ++
 tools/libs/foreignmemory/private.h |  30 ++
 tools/libxc/include/xc_dom.h   |   8 +-
 tools/libxc/xc_dom_boot.c  | 102 -
 tools/libxc/xc_sr_restore_x86_hvm.c|  10 +-
 tools/libxc/xc_sr_restore_x86_pv.c |   2 +-
 tools/libxl/libxl_dom.c|   1 -
 tools/python/xen/lowlevel/xc/xc.c  |   6 +-
 xen/arch/arm/mm.c  |  29 +-
 xen/arch/x86/hvm/dm.c  |  11 +-
 xen/arch/x86/hvm/hvm.c |   8 +-
 xen/arch/x86/hvm/io.c  |   4 +-
 xen/arch/x86/hvm/ioreq.c   | 453 -
 xen/arch/x86/mm.c  | 177 ++--
 xen/arch/x86/mm/p2m.c  |   3 +-
 xen/common/grant_table.c   |  33 ++
 xen/include/asm-x86/hvm/domain.h   |  11 +-
 xen/include/asm-x86/hvm/ioreq.h|  20 +-
 xen/include/asm-x86/p2m.h  |   3 +
 xen/include/public/hvm/dm_op.h |  46 ++-
 xen/include/public/memory.h|  41 +-
 xen/include/xen/grant_table.h  |   3 +
 29 files changed, 846 insertions(+), 331 deletions(-)

---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Julien Grall 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 

v2:
 - Support for IOREQ server pages added

-- 
2.11.0


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

[Xen-devel] [PATCH v2 REPOST 05/12] tools/libxenctrl: use new xenforeignmemory API to seed grant table

[Paul Durrant]

A previous patch added support for priv-mapping guest resources directly
(rather than having to foreign-map, which requires P2M modification for
HVM guests).

This patch makes use of the new API to seed the guest grant table unless
the underlying infrastructure (i.e. privcmd) doesn't support it, in which
case the old scheme is used.

NOTE: The call to xc_dom_gnttab_hvm_seed() in hvm_build_set_params() was
  actually unnecessary, as the grant table has already been seeded
  by a prior call to xc_dom_gnttab_init() made by libxl__build_dom().

Signed-off-by: Paul Durrant 
Acked-by: Marek Marczykowski-Górecki 
---
Cc: Ian Jackson 
Cc: Wei Liu 
---
 tools/libxc/include/xc_dom.h|   8 +--
 tools/libxc/xc_dom_boot.c   | 102 
 tools/libxc/xc_sr_restore_x86_hvm.c |  10 ++--
 tools/libxc/xc_sr_restore_x86_pv.c  |   2 +-
 tools/libxl/libxl_dom.c |   1 -
 tools/python/xen/lowlevel/xc/xc.c   |   6 +--
 6 files changed, 92 insertions(+), 37 deletions(-)

diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index ce47058c41..d6ca0a8680 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -323,12 +323,8 @@ void *xc_dom_boot_domU_map(struct xc_dom_image *dom, 
xen_pfn_t pfn,
 int xc_dom_boot_image(struct xc_dom_image *dom);
 int xc_dom_compat_check(struct xc_dom_image *dom);
 int xc_dom_gnttab_init(struct xc_dom_image *dom);
-int xc_dom_gnttab_hvm_seed(xc_interface *xch, domid_t domid,
-   xen_pfn_t console_gmfn,
-   xen_pfn_t xenstore_gmfn,
-   domid_t console_domid,
-   domid_t xenstore_domid);
-int xc_dom_gnttab_seed(xc_interface *xch, domid_t domid,
+int xc_dom_gnttab_seed(xc_interface *xch, domid_t guest_domid,
+   bool is_hvm,
xen_pfn_t console_gmfn,
xen_pfn_t xenstore_gmfn,
domid_t console_domid,
diff --git a/tools/libxc/xc_dom_boot.c b/tools/libxc/xc_dom_boot.c
index c3b44dd399..fc3174ad7e 100644
--- a/tools/libxc/xc_dom_boot.c
+++ b/tools/libxc/xc_dom_boot.c
@@ -280,11 +280,11 @@ static xen_pfn_t xc_dom_gnttab_setup(xc_interface *xch, 
domid_t domid)
 return gmfn;
 }
 
-int xc_dom_gnttab_seed(xc_interface *xch, domid_t domid,
-   xen_pfn_t console_gmfn,
-   xen_pfn_t xenstore_gmfn,
-   domid_t console_domid,
-   domid_t xenstore_domid)
+static int compat_gnttab_seed(xc_interface *xch, domid_t domid,
+  xen_pfn_t console_gmfn,
+  xen_pfn_t xenstore_gmfn,
+  domid_t console_domid,
+  domid_t xenstore_domid)
 {
 
 xen_pfn_t gnttab_gmfn;
@@ -337,11 +337,11 @@ int xc_dom_gnttab_seed(xc_interface *xch, domid_t domid,
 return 0;
 }
 
-int xc_dom_gnttab_hvm_seed(xc_interface *xch, domid_t domid,
-   xen_pfn_t console_gpfn,
-   xen_pfn_t xenstore_gpfn,
-   domid_t console_domid,
-   domid_t xenstore_domid)
+static int compat_gnttab_hvm_seed(xc_interface *xch, domid_t domid,
+  xen_pfn_t console_gpfn,
+  xen_pfn_t xenstore_gpfn,
+  domid_t console_domid,
+  domid_t xenstore_domid)
 {
 int rc;
 xen_pfn_t scratch_gpfn;
@@ -380,7 +380,7 @@ int xc_dom_gnttab_hvm_seed(xc_interface *xch, domid_t domid,
 return -1;
 }
 
-rc = xc_dom_gnttab_seed(xch, domid,
+rc = compat_gnttab_seed(xch, domid,
 console_gpfn, xenstore_gpfn,
 console_domid, xenstore_domid);
 if (rc != 0)
@@ -405,18 +405,78 @@ int xc_dom_gnttab_hvm_seed(xc_interface *xch, domid_t 
domid,
 return 0;
 }
 
-int xc_dom_gnttab_init(struct xc_dom_image *dom)
+int xc_dom_gnttab_seed(xc_interface *xch, domid_t guest_domid,
+   bool is_hvm, xen_pfn_t console_gmfn,
+   xen_pfn_t xenstore_gmfn, domid_t console_domid,
+   domid_t xenstore_domid)
 {
-if ( xc_dom_translated(dom) ) {
-return xc_dom_gnttab_hvm_seed(dom->xch, dom->guest_domid,
-  dom->console_pfn, dom->xenstore_pfn,
-  dom->console_domid, dom->xenstore_domid);
-} else {
-return xc_dom_gnttab_seed(dom->xch, dom->guest_domid,
-  xc_dom_p2m(dom, dom->console_pfn),
-  xc_dom_p2m(dom, dom->xenstore_pfn),
-  dom->console_domid, dom->xenstore_domid);
+

[Xen-devel] [PATCH v2 REPOST 02/12] x86/mm: allow a privileged PV domain to map guest mfns

[Paul Durrant]

In the case where a PV domain is mapping guest resources then it needs make
the HYPERVISOR_mmu_update call using DOMID_SELF, rather than the guest
domid, so that the passed in gmfn values are correctly treated as mfns
rather than gfns present in the guest p2m.

This patch removes a check which currently disallows mapping of a page when
the owner of the page tables matches the domain passed to
HYPERVISOR_mmu_update, but that domain is not the real owner of the page.
The check was introduced by patch d3c6a215ca9 ("x86: Clean up
get_page_from_l1e() to correctly distinguish between owner-of-pte and
owner-of-data-page in all cases") but it's not clear why it was needed.

Signed-off-by: Paul Durrant 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/x86/mm.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 0abb1e284f..aaa9ff5197 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -989,12 +989,15 @@ get_page_from_l1e(
(real_pg_owner != dom_cow) ) )
 {
 /*
- * Let privileged domains transfer the right to map their target
- * domain's pages. This is used to allow stub-domain pvfb export to
- * dom0, until pvfb supports granted mappings. At that time this
- * minor hack can go away.
+ * If the real page owner is not the domain specified in the
+ * hypercall then establish that the specified domain has
+ * mapping privilege over the page owner.
+ * This is used to allow stub-domain pvfb export to dom0. It is
+ * also used to allow a privileged PV domain to map mfns using
+ * DOMID_SELF, which is needed for mapping guest resources such
+ * grant table frames.
  */
-if ( (real_pg_owner == NULL) || (pg_owner == l1e_owner) ||
+if ( (real_pg_owner == NULL) ||
  xsm_priv_mapping(XSM_TARGET, pg_owner, real_pg_owner) )
 {
 gdprintk(XENLOG_WARNING,
-- 
2.11.0


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

[Xen-devel] [PATCH v2 REPOST 03/12] x86/mm: add HYPERVISOR_memory_op to acquire guest resources

[Paul Durrant]

Certain memory resources associated with a guest are not necessarily
present in the guest P2M and so are not necessarily available to be
foreign-mapped by a tools domain unless they are inserted, which risks
shattering a super-page mapping.

This patch adds a new memory op to allow such resourced to be priv-mapped
directly, by either a PV or HVM tools domain.

NOTE: Whilst the new op is not intrinsicly specific to the x86 architecture,
  I have no means to test it on an ARM platform and so cannot verify
  that it functions correctly. Hence it is currently only implemented
  for x86.

Signed-off-by: Paul Durrant 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: George Dunlap 
---
 xen/arch/x86/mm.c   | 111 
 xen/arch/x86/mm/p2m.c   |   3 +-
 xen/include/asm-x86/p2m.h   |   3 ++
 xen/include/public/memory.h |  38 ++-
 4 files changed, 152 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index aaa9ff5197..4e86f0a2ab 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4717,6 +4717,107 @@ int xenmem_add_to_physmap_one(
 return rc;
 }
 
+static int xenmem_acquire_grant_table(struct domain *d,
+  unsigned long frame,
+  unsigned long nr_frames,
+  unsigned long mfn_list[])
+{
+unsigned int i;
+
+/*
+ * Iterate through the list backwards so that gnttab_get_frame() is
+ * first called for the highest numbered frame. This means that the
+ * out-of-bounds check will be done on the first iteration and, if
+ * the table needs to grow, it will only grow once.
+ */
+i = nr_frames;
+while ( i-- != 0 )
+{
+mfn_t mfn = gnttab_get_frame(d, frame + i);
+
+if ( mfn_eq(mfn, INVALID_MFN) )
+return -EINVAL;
+
+mfn_list[i] = mfn_x(mfn);
+}
+
+return 0;
+}
+
+static int xenmem_acquire_resource(xen_mem_acquire_resource_t *xmar)
+{
+struct domain *d, *currd = current->domain;
+unsigned long *mfn_list;
+int rc;
+
+if ( xmar->nr_frames == 0 )
+return -EINVAL;
+
+d = rcu_lock_domain_by_any_id(xmar->domid);
+if ( d == NULL )
+return -ESRCH;
+
+rc = xsm_domain_memory_map(XSM_TARGET, d);
+if ( rc )
+goto out;
+
+mfn_list = xmalloc_array(unsigned long, xmar->nr_frames);
+
+rc = -ENOMEM;
+if ( !mfn_list )
+goto out;
+
+switch ( xmar->type )
+{
+case XENMEM_resource_grant_table:
+rc = -EINVAL;
+if ( xmar->id ) /* must be zero for grant_table */
+break;
+
+rc = xenmem_acquire_grant_table(d, xmar->frame, xmar->nr_frames,
+mfn_list);
+break;
+
+default:
+rc = -EOPNOTSUPP;
+break;
+}
+
+if ( rc )
+goto free_and_out;
+
+if ( !paging_mode_translate(currd) )
+{
+if ( __copy_to_guest_offset(xmar->gmfn_list, 0, mfn_list,
+xmar->nr_frames) )
+rc = -EFAULT;
+}
+else
+{
+unsigned int i;
+
+for ( i = 0; i < xmar->nr_frames; i++ )
+{
+xen_pfn_t gfn;
+
+rc = -EFAULT;
+if ( __copy_from_guest_offset(, xmar->gmfn_list, i, 1) )
+goto free_and_out;
+
+rc = set_foreign_p2m_entry(currd, gfn, _mfn(mfn_list[i]));
+if ( rc )
+goto free_and_out;
+}
+}
+
+ free_and_out:
+xfree(mfn_list);
+
+ out:
+rcu_unlock_domain(d);
+return rc;
+}
+
 long arch_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
 int rc;
@@ -4939,6 +5040,16 @@ long arch_memory_op(unsigned long cmd, 
XEN_GUEST_HANDLE_PARAM(void) arg)
 return rc;
 }
 
+case XENMEM_acquire_resource:
+{
+xen_mem_acquire_resource_t xmar;
+
+if ( copy_from_guest(, arg, 1) )
+return -EFAULT;
+
+return xenmem_acquire_resource();
+}
+
 default:
 return subarch_memory_op(cmd, arg);
 }
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index e8a57d118c..c503a7f1d2 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1118,8 +1118,7 @@ static int set_typed_p2m_entry(struct domain *d, unsigned 
long gfn, mfn_t mfn,
 }
 
 /* Set foreign mfn in the given guest's p2m table. */
-static int set_foreign_p2m_entry(struct domain *d, unsigned long gfn,
- mfn_t mfn)
+int set_foreign_p2m_entry(struct domain *d, unsigned long gfn, mfn_t mfn)
 {
 return set_typed_p2m_entry(d, gfn, mfn, PAGE_ORDER_4K, p2m_map_foreign,
p2m_get_hostp2m(d)->default_access);
diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
index 

[Xen-devel] [PATCH v2 REPOST 06/12] x86/hvm/ioreq: rename .*pfn and .*gmfn to .*gfn

[Paul Durrant]

Since IOREQ servers are only relevant to HVM guests and all the names in
question unequivocally refer to guest frame numbers, name them all .*gfn
to avoid any confusion.

This patch is purely cosmetic. No semantic or functional change.

Signed-off-by: Paul Durrant 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 tools/libs/devicemodel/core.c   | 10 ++--
 tools/libs/devicemodel/include/xendevicemodel.h | 12 ++--
 xen/arch/x86/hvm/dm.c   |  4 +-
 xen/arch/x86/hvm/hvm.c  |  6 +-
 xen/arch/x86/hvm/ioreq.c| 74 -
 xen/include/asm-x86/hvm/domain.h|  4 +-
 xen/include/asm-x86/hvm/ioreq.h |  4 +-
 xen/include/public/hvm/dm_op.h  | 20 +++
 8 files changed, 67 insertions(+), 67 deletions(-)

diff --git a/tools/libs/devicemodel/core.c b/tools/libs/devicemodel/core.c
index d7c6476006..fcb260d29b 100644
--- a/tools/libs/devicemodel/core.c
+++ b/tools/libs/devicemodel/core.c
@@ -174,7 +174,7 @@ int xendevicemodel_create_ioreq_server(
 
 int xendevicemodel_get_ioreq_server_info(
 xendevicemodel_handle *dmod, domid_t domid, ioservid_t id,
-xen_pfn_t *ioreq_pfn, xen_pfn_t *bufioreq_pfn,
+xen_pfn_t *ioreq_gfn, xen_pfn_t *bufioreq_gfn,
 evtchn_port_t *bufioreq_port)
 {
 struct xen_dm_op op;
@@ -192,11 +192,11 @@ int xendevicemodel_get_ioreq_server_info(
 if (rc)
 return rc;
 
-if (ioreq_pfn)
-*ioreq_pfn = data->ioreq_pfn;
+if (ioreq_gfn)
+*ioreq_gfn = data->ioreq_gfn;
 
-if (bufioreq_pfn)
-*bufioreq_pfn = data->bufioreq_pfn;
+if (bufioreq_gfn)
+*bufioreq_gfn = data->bufioreq_gfn;
 
 if (bufioreq_port)
 *bufioreq_port = data->bufioreq_port;
diff --git a/tools/libs/devicemodel/include/xendevicemodel.h 
b/tools/libs/devicemodel/include/xendevicemodel.h
index 580fad2f49..13216db04a 100644
--- a/tools/libs/devicemodel/include/xendevicemodel.h
+++ b/tools/libs/devicemodel/include/xendevicemodel.h
@@ -60,17 +60,17 @@ int xendevicemodel_create_ioreq_server(
  * @parm dmod a handle to an open devicemodel interface.
  * @parm domid the domain id to be serviced
  * @parm id the IOREQ Server id.
- * @parm ioreq_pfn pointer to a xen_pfn_t to receive the synchronous ioreq
- *  gmfn
- * @parm bufioreq_pfn pointer to a xen_pfn_t to receive the buffered ioreq
- *gmfn
+ * @parm ioreq_gfn pointer to a xen_pfn_t to receive the synchronous ioreq
+ *  gfn
+ * @parm bufioreq_gfn pointer to a xen_pfn_t to receive the buffered ioreq
+ *gfn
  * @parm bufioreq_port pointer to a evtchn_port_t to receive the buffered
  * ioreq event channel
  * @return 0 on success, -1 on failure.
  */
 int xendevicemodel_get_ioreq_server_info(
 xendevicemodel_handle *dmod, domid_t domid, ioservid_t id,
-xen_pfn_t *ioreq_pfn, xen_pfn_t *bufioreq_pfn,
+xen_pfn_t *ioreq_gfn, xen_pfn_t *bufioreq_gfn,
 evtchn_port_t *bufioreq_port);
 
 /**
@@ -168,7 +168,7 @@ int xendevicemodel_destroy_ioreq_server(
  * This function sets IOREQ Server state. An IOREQ Server
  * will not be passed emulation requests until it is in
  * the enabled state.
- * Note that the contents of the ioreq_pfn and bufioreq_pfn are
+ * Note that the contents of the ioreq_gfn and bufioreq_gfn are
  * not meaningful until the IOREQ Server is in the enabled state.
  *
  * @parm dmod a handle to an open devicemodel interface.
diff --git a/xen/arch/x86/hvm/dm.c b/xen/arch/x86/hvm/dm.c
index 4cf6deedc7..f7cb883fec 100644
--- a/xen/arch/x86/hvm/dm.c
+++ b/xen/arch/x86/hvm/dm.c
@@ -426,8 +426,8 @@ static int dm_op(const struct dmop_args *op_args)
 break;
 
 rc = hvm_get_ioreq_server_info(d, data->id,
-   >ioreq_pfn,
-   >bufioreq_pfn,
+   >ioreq_gfn,
+   >bufioreq_gfn,
>bufioreq_port);
 break;
 }
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 6cb903def5..58b4afa1d1 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4185,20 +4185,20 @@ static int hvmop_set_param(
 rc = -EINVAL;
 break;
 case HVM_PARAM_IOREQ_SERVER_PFN:
-d->arch.hvm_domain.ioreq_gmfn.base = a.value;
+d->arch.hvm_domain.ioreq_gfn.base = a.value;
 break;
 case HVM_PARAM_NR_IOREQ_SERVER_PAGES:
 {
 unsigned int i;
 
 if ( a.value == 0 ||
- a.value > sizeof(d->arch.hvm_domain.ioreq_gmfn.mask) * 8 )
+ a.value > sizeof(d->arch.hvm_domain.ioreq_gfn.mask) * 8 )
 {
 rc = -EINVAL;
 break;
 }
 for ( i = 0; i < a.value; i++ )
-

[Xen-devel] [PATCH v2 REPOST 07/12] x86/hvm/ioreq: use bool rather than bool_t

[Paul Durrant]

This patch changes use of bool_t to bool in the IOREQ server code. It also
fixes an incorrect indentation in a continuation line.

This patch is purely cosmetic. No semantic or functional change.

Signed-off-by: Paul Durrant 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/x86/hvm/dm.c|   2 +-
 xen/arch/x86/hvm/hvm.c   |   2 +-
 xen/arch/x86/hvm/io.c|   4 +-
 xen/arch/x86/hvm/ioreq.c | 100 +++
 xen/include/asm-x86/hvm/domain.h |   6 +--
 xen/include/asm-x86/hvm/ioreq.h  |  14 +++---
 6 files changed, 64 insertions(+), 64 deletions(-)

diff --git a/xen/arch/x86/hvm/dm.c b/xen/arch/x86/hvm/dm.c
index f7cb883fec..87ef4b6ca9 100644
--- a/xen/arch/x86/hvm/dm.c
+++ b/xen/arch/x86/hvm/dm.c
@@ -409,7 +409,7 @@ static int dm_op(const struct dmop_args *op_args)
 if ( data->pad[0] || data->pad[1] || data->pad[2] )
 break;
 
-rc = hvm_create_ioreq_server(d, curr_d->domain_id, 0,
+rc = hvm_create_ioreq_server(d, curr_d->domain_id, false,
  data->handle_bufioreq, >id);
 break;
 }
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 58b4afa1d1..031d07baf0 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4361,7 +4361,7 @@ static int hvmop_get_param(
 {
 domid_t domid = d->arch.hvm_domain.params[HVM_PARAM_DM_DOMAIN];
 
-rc = hvm_create_ioreq_server(d, domid, 1,
+rc = hvm_create_ioreq_server(d, domid, true,
  HVM_IOREQSRV_BUFIOREQ_LEGACY, NULL);
 if ( rc != 0 && rc != -EEXIST )
 goto out;
diff --git a/xen/arch/x86/hvm/io.c b/xen/arch/x86/hvm/io.c
index 214ab307c4..bfac993223 100644
--- a/xen/arch/x86/hvm/io.c
+++ b/xen/arch/x86/hvm/io.c
@@ -59,7 +59,7 @@ void send_timeoffset_req(unsigned long timeoff)
 if ( timeoff == 0 )
 return;
 
-if ( hvm_broadcast_ioreq(, 1) != 0 )
+if ( hvm_broadcast_ioreq(, true) != 0 )
 gprintk(XENLOG_ERR, "Unsuccessful timeoffset update\n");
 }
 
@@ -73,7 +73,7 @@ void send_invalidate_req(void)
 .data = ~0UL, /* flush all */
 };
 
-if ( hvm_broadcast_ioreq(, 0) != 0 )
+if ( hvm_broadcast_ioreq(, false) != 0 )
 gprintk(XENLOG_ERR, "Unsuccessful map-cache invalidate\n");
 }
 
diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index 3e753ba224..5e01e1a6d2 100644
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -43,7 +43,7 @@ static ioreq_t *get_ioreq(struct hvm_ioreq_server *s, struct 
vcpu *v)
 return >vcpu_ioreq[v->vcpu_id];
 }
 
-bool_t hvm_io_pending(struct vcpu *v)
+bool hvm_io_pending(struct vcpu *v)
 {
 struct domain *d = v->domain;
 struct hvm_ioreq_server *s;
@@ -59,11 +59,11 @@ bool_t hvm_io_pending(struct vcpu *v)
   list_entry )
 {
 if ( sv->vcpu == v && sv->pending )
-return 1;
+return true;
 }
 }
 
-return 0;
+return false;
 }
 
 static void hvm_io_assist(struct hvm_ioreq_vcpu *sv, uint64_t data)
@@ -82,10 +82,10 @@ static void hvm_io_assist(struct hvm_ioreq_vcpu *sv, 
uint64_t data)
 msix_write_completion(v);
 vcpu_end_shutdown_deferral(v);
 
-sv->pending = 0;
+sv->pending = false;
 }
 
-static bool_t hvm_wait_for_io(struct hvm_ioreq_vcpu *sv, ioreq_t *p)
+static bool hvm_wait_for_io(struct hvm_ioreq_vcpu *sv, ioreq_t *p)
 {
 while ( sv->pending )
 {
@@ -112,16 +112,16 @@ static bool_t hvm_wait_for_io(struct hvm_ioreq_vcpu *sv, 
ioreq_t *p)
 break;
 default:
 gdprintk(XENLOG_ERR, "Weird HVM iorequest state %u\n", state);
-sv->pending = 0;
+sv->pending = false;
 domain_crash(sv->vcpu->domain);
-return 0; /* bail */
+return false; /* bail */
 }
 }
 
-return 1;
+return true;
 }
 
-bool_t handle_hvm_io_completion(struct vcpu *v)
+bool handle_hvm_io_completion(struct vcpu *v)
 {
 struct domain *d = v->domain;
 struct hvm_vcpu_io *vio = >arch.hvm_vcpu.hvm_io;
@@ -141,7 +141,7 @@ bool_t handle_hvm_io_completion(struct vcpu *v)
 if ( sv->vcpu == v && sv->pending )
 {
 if ( !hvm_wait_for_io(sv, get_ioreq(s, v)) )
-return 0;
+return false;
 
 break;
 }
@@ -178,7 +178,7 @@ bool_t handle_hvm_io_completion(struct vcpu *v)
 break;
 }
 
-return 1;
+return true;
 }
 
 static int hvm_alloc_ioreq_gfn(struct domain *d, unsigned long *gfn)
@@ -208,7 +208,7 @@ static void hvm_free_ioreq_gfn(struct domain *d, unsigned 
long gfn)
 set_bit(i, >arch.hvm_domain.ioreq_gfn.mask);
 }
 
-static void hvm_unmap_ioreq_page(struct hvm_ioreq_server *s, bool_t buf)
+static 

Re: [Xen-devel] [PATCH 10/27] xen/arm: arm32: Don't define FAR_EL1

[Andre Przywara]

Hi,

On 14/08/17 15:24, Julien Grall wrote:
> Aliasing FAR_EL1 to IFAR is wrong because on ARMv8 FAR_EL1[31:0] is
> architecturally mapped to DFAR and FAR_EL1[63:32] to DFAR.
   
Should be IFAR, I guess?
Please put a quid into the copy-and-paste piggy bank ;-)

Otherwise it's fine.

> As FAR_EL1 is not currently used in ARM32 code, remove it.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Andre Przywara 

Cheers,
Andre.

> ---
>  xen/include/asm-arm/cpregs.h | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
> index 1889d7cbfb..9e138489f0 100644
> --- a/xen/include/asm-arm/cpregs.h
> +++ b/xen/include/asm-arm/cpregs.h
> @@ -306,7 +306,6 @@
>  #define DACR32_EL2  DACR
>  #define ESR_EL1 DFSR
>  #define ESR_EL2 HSR
> -#define FAR_EL1 HIFAR
>  #define HCR_EL2 HCR
>  #define HPFAR_EL2   HPFAR
>  #define HSTR_EL2HSTR
> 

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

Re: [Xen-devel] [PATCH v4 03/11] public: xen.h: add definitions for UUID handling

[Volodymyr Babchuk]

Hi Jan,

On 22.08.17 10:26, Jan Beulich wrote:

On 21.08.17 at 22:27,  wrote:

--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -930,6 +930,15 @@ __DEFINE_XEN_GUEST_HANDLE(uint16, uint16_t);
  __DEFINE_XEN_GUEST_HANDLE(uint32, uint32_t);
  __DEFINE_XEN_GUEST_HANDLE(uint64, uint64_t);
  
+typedef uint8_t xen_uuid_t[16];


As expressed before, I'm opposed to this being a plain array. I've
pointed you at the EFI representation as an example; at the very
least I'd expect a wrapper structure around the array (which is
_not_ to say that I would ack such a patch, but at least I wouldn't
nak it).


EFI code uses GUID, which is product of Microsoft's NIH syndrome.

Let me cite some parts of RFC 4122:

4.1.  Format

   *The UUID format is 16 octets*; some bits of the eight octet variant
   field specified below determine finer structure.
.

4.1.2.  Layout and Byte Order
.
   In the absence of explicit application or presentation protocol
   specification to the contrary, a UUID is encoded as a 128-bit object,
   as follows:

   The fields are encoded as 16 octets, with the sizes and order of the
   fields defined above, and with each field encoded with the Most
   Significant Byte first (known as network byte order).  Note that the
   field names, particularly for multiplexed fields, follow historical
   practice.

   0   1   2   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  time_low |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   time_mid| time_hi_and_version   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |clk_seq_hi_res |  clk_seq_low  | node (0-1)|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | node (2-5)|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.


BTW, GUID handling is incompatible with this RFC, because in GUID
first three fields are stored in LE format, while other fields are 
stored in BE format.


I can't see why you want to map UUID to a certain structure. I can 
create such wrapper, but it will be just dead code, because there are no 
users for it. Frankly, I can't imagine why someone will want to read, 
say, clk_seq_hi_res field of UUID.


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

Re: [Xen-devel] [PATCH 00/25 v7] SBSA UART emulation support in Xen

[Julien Grall]

Hi,

A quick update below.

On 14/08/17 14:54, Julien Grall wrote:

On 14/08/17 08:52, Bhupinder Thakur wrote:

I could not reproduce the issue with the reduced buffer of 16 bytes
also. I think it may not be reproducible on the foundation model. I am
trying to bring up xen on an ARM machine here to reproduce the issue.

While looking at the pl011 driver in linux, I see one potential case
where the the driver may send more data even when the TX FIFO is full.
It seems the pl011 driver expects that the TX interrupt must be raised
only when at least half of TX FIFO queue is empty.

pl011_tx_chars() calls pl011_tx_char() in a loop for (fifosize/2)
number of times. Since these APIs are getting called in the interrupt
context, pl011_tx_char() does not check for TX FIFO full status
because it expects that fifosize/2 space is available.

In the emulation logic, we should set the TX bit in the status
register only if at least space for 16 bytes is available (since SBSA
fifosize is 32). Currently, we may be setting the TX bit even if there
is space for 1 byte. In that scenario, the driver may write more data
then emulation logic can queue up.


I understand that it is the behavior expected by Linux. However did you
check it was compliant with the spec?

If I looked at the PL011 (ARM DDI 0183G), the interrupt FIFO level is
set via UARTIFLS. The reset value is half-way mark (i.e 16 byte).

However, looking at the SBSA, this register is inexistent and I can't
find anything mentioning the half-way mark. So we need some
clarification here. Let me ask it.

Meanwhile, trying the half-way mark would be good to see if it helps.


I got the confirmation that some clarification is needed in the spec. 
Until this is done, we should assume the halfway mark in our emulation.


Cheers,



Cheers,



--
Julien Grall

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

Re: [Xen-devel] [PATCH v2 2/3] tools/libxc: add API for bitmap access for restore

[Wei Liu]

On Thu, Aug 17, 2017 at 07:01:32PM +0200, Olaf Hering wrote:
> Extend API for managing bitmaps. Each bitmap is now represented by a
> generic struct xc_sr_bitmap.
> Switch the existing populated_pfns to this API.
> 
> Signed-off-by: Olaf Hering 
> +
[...]
> +static inline void xc_sr_bitmap_free(struct xc_sr_bitmap *bm)
> +{
> +free(bm->p);

Also set bm->p to NULL to make it idempotent please.

> +}
> +
> +static inline bool xc_sr_set_bit(unsigned long bit, struct xc_sr_bitmap *bm)
> +{
> +if (!xc_sr_bitmap_resize(bm, bit))
> +return false;
> +
> +set_bit(bit, bm->p);
> +return true;
> +}
> +
> +static inline bool xc_sr_test_bit(unsigned long bit, struct xc_sr_bitmap *bm)
> +{
> +if (bit > bm->bits)
> +return false;
> +return !!test_bit(bit, bm->p);
> +}
> +
> +static inline int xc_sr_test_and_clear_bit(unsigned long bit, struct 
> xc_sr_bitmap *bm)
> +{
> +return test_and_clear_bit(bit, bm->p);
> +}
> +
> +static inline int xc_sr_test_and_set_bit(unsigned long bit, struct 
> xc_sr_bitmap *bm)
> +{
> +return test_and_set_bit(bit, bm->p);
> +}
> +
> +static inline bool pfn_is_populated(struct xc_sr_context *ctx, xen_pfn_t pfn)
> +{
> +return xc_sr_test_bit(pfn, >restore.populated_pfns);
> +}
> +
> +static inline int pfn_set_populated(struct xc_sr_context *ctx, xen_pfn_t pfn)
> +{
> +xc_interface *xch = ctx->xch;
> +

This is not used, right?

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

Re: [Xen-devel] [PATCH V2 1/25] DOMCTL: Introduce new DOMCTL commands for vIOMMU support

[Roger Pau Monné]

On Wed, Aug 09, 2017 at 04:34:02PM -0400, Lan Tianyu wrote:
> This patch is to introduce create, destroy and query capabilities
> command for vIOMMU. vIOMMU layer will deal with requests and call
> arch vIOMMU ops.
> 
> Signed-off-by: Lan Tianyu 
> ---
>  xen/common/domctl.c |  3 +++
>  xen/common/viommu.c | 43 +

I'm confused, I don't see this file in the repo, and the cover letter
doesn't mention this being based on top of any other series, where
does this viommu.c file come from?

>  xen/include/public/domctl.h | 52 
> +
>  xen/include/xen/viommu.h|  6 ++
>  4 files changed, 104 insertions(+)
> 
> diff --git a/xen/common/domctl.c b/xen/common/domctl.c
> index d80488b..01c3024 100644
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -1144,6 +1144,9 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) 
> u_domctl)
>  if ( !ret )
>  copyback = 1;
>  break;
> +case XEN_DOMCTL_viommu_op:
> +ret = viommu_domctl(d, >u.viommu_op, );
> +break;

Hm, shouldn't this be protected with #ifdef CONFIG_VIOMMU?

>  default:
>  ret = arch_do_domctl(op, d, u_domctl);
> diff --git a/xen/common/viommu.c b/xen/common/viommu.c
> index 6874d9f..a4d004d 100644
> --- a/xen/common/viommu.c
> +++ b/xen/common/viommu.c
> @@ -148,6 +148,49 @@ static u64 viommu_query_caps(struct domain *d, u64 type)
>  return viommu_type->ops->query_caps(d);
>  }
>  
> +int viommu_domctl(struct domain *d, struct xen_domctl_viommu_op *op,
> +  bool *need_copy)
> +{
> +int rc = -EINVAL, ret;

Do you really need both ret and rc?

> +if ( !viommu_enabled() )
> +return rc;

EINVAL? Maybe ENODEV?

> +
> +switch ( op->cmd )
> +{
> +case XEN_DOMCTL_create_viommu:
> +ret = viommu_create(d, op->u.create_viommu.viommu_type,
> +op->u.create_viommu.base_address,
> +op->u.create_viommu.length,
> +op->u.create_viommu.capabilities);

I would rather prefer for viommu_create to simply return an error or
0, and store the viommu_id by passing a pointer parameter to viommu_create, ie:

rc = viommu_create(d, op->u.create_viommu.viommu_type,
   op->u.create_viommu.base_address,
   op->u.create_viommu.length,
   op->u.create_viommu.capabilities,
   >u.create_viommu.viommu_id);

> +if ( ret >= 0 ) {
   ^ coding style
> +op->u.create_viommu.viommu_id = ret;
> +*need_copy = true;
> +rc = 0; /* return 0 if success */
> +}
> +break;
> +
> +case XEN_DOMCTL_destroy_viommu:
> +rc = viommu_destroy(d, op->u.destroy_viommu.viommu_id);
> +break;
> +
> +case XEN_DOMCTL_query_viommu_caps:
> +ret = viommu_query_caps(d, op->u.query_caps.viommu_type);

Same here, I would rather pass another parameter and use the return
for error only.

> +if ( ret >= 0 )
> +{
> +op->u.query_caps.capabilities = ret;
> +rc = 0;
> +}
> +*need_copy = true;
> +break;
> +
> +default:
> +break;

Here you should return ENOSYS.

> +}
> +
> +return rc;
> +}
> +
>  int __init viommu_setup(void)
>  {
>  INIT_LIST_HEAD(_list);
> diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
> index ff39762..4b10f26 100644
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -1149,6 +1149,56 @@ struct xen_domctl_psr_cat_op {
>  typedef struct xen_domctl_psr_cat_op xen_domctl_psr_cat_op_t;
>  DEFINE_XEN_GUEST_HANDLE(xen_domctl_psr_cat_op_t);
>  
> +/*  vIOMMU helper
> + *
> + *  vIOMMU interface can be used to create/destroy vIOMMU and
> + *  query vIOMMU capabilities.
> + */
> +
> +/* vIOMMU type - specify vendor vIOMMU device model */
> +#define VIOMMU_TYPE_INTEL_VTD (1u << 0)

If this going to be used to specify the vendor only, it doesn't need
to be a bitfield, because it doesn't make sense to specify for
example VIOMMU_TYPE_INTEL_VTD | VIOMMU_TYPE_AMD, it's either Intel or
AMD. Do you have plans to expand this with other uses? In which case
the comment should be fixed.

> +
> +/* vIOMMU capabilities */
> +#define VIOMMU_CAP_IRQ_REMAPPING  (1u << 0)
> +
> +struct xen_domctl_viommu_op {
> +uint32_t cmd;
> +#define XEN_DOMCTL_create_viommu  0
> +#define XEN_DOMCTL_destroy_viommu 1
> +#define XEN_DOMCTL_query_viommu_caps  2
> +union {
> +struct {
> +/* IN - vIOMMU type */
> +uint64_t viommu_type;
> +/* 
> + * IN - MMIO base address of vIOMMU. vIOMMU device models
> + * are in charge of to check base_address and length.
> + */
> +uint64_t base_address;
> +/* IN - Length of MMIO region */
> +

Re: [Xen-devel] [PATCH 08/27] xen/arm: hsr_iabt: Document RES0 field

[Julien Grall]

On 22/08/17 15:21, Andre Przywara wrote:

Hi,


Hi Andre,



On 14/08/17 15:23, Julien Grall wrote:

Signed-off-by: Julien Grall 


Reviewed-by: Andre Przywara 


---
 xen/include/asm-arm/processor.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index ab5225fa6c..51645f08c0 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -505,9 +505,9 @@ union hsr {

 struct hsr_iabt {
 unsigned long ifsc:6;  /* Instruction fault status code */
-unsigned long res0:1;
+unsigned long res0:1;  /* RES0 */
 unsigned long s1ptw:1; /* Stage 2 fault during stage 1 translation */
-unsigned long res1:1;
+unsigned long res1:1;  /* RES0 */
 unsigned long eat:1;   /* External abort type */
 unsigned long res2:15;


As we are at it: newer versions of the ARM ARM have the "FnV" bit here
at bit 10, so would it be worth to update it as:


See patch 11 :). I would prefer if we keep "clean-up" out of new 
addition for the review.


Cheers,



   unsigned long fnv:1;   /* FAR not Valid */
   unsigned long res2:14;



--
Julien Grall

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

Re: [Xen-devel] [PATCH v2 1/3] tools/libxc: move SUPERPAGE macros to common header

[Wei Liu]

On Thu, Aug 17, 2017 at 07:01:31PM +0200, Olaf Hering wrote:
> The macros SUPERPAGE_2MB_SHIFT and SUPERPAGE_1GB_SHIFT will be used by
> other code in libxc. Move the macros to a header file.
> 
> Signed-off-by: Olaf Hering 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH 08/27] xen/arm: hsr_iabt: Document RES0 field

[Andre Przywara]

Hi,

On 14/08/17 15:23, Julien Grall wrote:
> Signed-off-by: Julien Grall 

Reviewed-by: Andre Przywara 

> ---
>  xen/include/asm-arm/processor.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
> index ab5225fa6c..51645f08c0 100644
> --- a/xen/include/asm-arm/processor.h
> +++ b/xen/include/asm-arm/processor.h
> @@ -505,9 +505,9 @@ union hsr {
>  
>  struct hsr_iabt {
>  unsigned long ifsc:6;  /* Instruction fault status code */
> -unsigned long res0:1;
> +unsigned long res0:1;  /* RES0 */
>  unsigned long s1ptw:1; /* Stage 2 fault during stage 1 translation */
> -unsigned long res1:1;
> +unsigned long res1:1;  /* RES0 */
>  unsigned long eat:1;   /* External abort type */
>  unsigned long res2:15;

As we are at it: newer versions of the ARM ARM have the "FnV" bit here
at bit 10, so would it be worth to update it as:

   unsigned long fnv:1;   /* FAR not Valid */
   unsigned long res2:14;

Cheers,
Andre.

>  unsigned long len:1;   /* Instruction length */
> 

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

Re: [Xen-devel] [PATCH v3] hvmloader, libxl: use the correct ACPI settings depending on device model

[Wei Liu]

On Thu, Aug 17, 2017 at 03:57:13PM +0100, Igor Druzhinin wrote:
> We need to choose ACPI tables and ACPI IO port location
> properly depending on the device model version we are running.
> Previously, this decision was made by BIOS type specific
> code in hvmloader, e.g. always load QEMU traditional specific
> tables if it's ROMBIOS and always load QEMU Xen specific
> tables if it's SeaBIOS.
> 
> This change saves this behavior (for compatibility) but adds
> an additional way (xenstore key) to specify the correct
> device model if we happen to run a non-default one. Toolstack
> bit makes use of it.
> 
> The enforcement of BIOS type depending on QEMU version will
> be lifted later when the rest of ROMBIOS compatibility fixes
> are in place.
> 
> Signed-off-by: Igor Druzhinin 
> Reviewed-by: Paul Durrant 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v6] x86/hvm: Allow guest_request vm_events coming from userspace

[Wei Liu]

On Thu, Aug 17, 2017 at 02:50:19PM +0300, Alexandru Isaila wrote:
> In some introspection usecases, an in-guest agent needs to communicate
> with the external introspection agent.  An existing mechanism is
> HVMOP_guest_request_vm_event, but this is restricted to kernel usecases
> like all other hypercalls.
> 
> Introduce a mechanism whereby the introspection agent can whitelist the
> use of HVMOP_guest_request_vm_event directly from userspace.
> 
> Signed-off-by: Alexandru Isaila 
> 
> ---
> Changes since V5:
>   - Added the bool allow_userspace to the xc_monitor_guest_request
>function
> ---
>  tools/libxc/include/xenctrl.h |  2 +-
>  tools/libxc/xc_monitor.c  |  3 ++-

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v3 52/52] xen: make some console related parameters settable at runtime

[Wei Liu]

On Wed, Aug 16, 2017 at 02:52:19PM +0200, Juergen Gross wrote:
> Support modifying conswitch, console_timestamps, loglvl and
> guest_loglvl at runtime.
> 
> Cc: Andrew Cooper 
> Cc: George Dunlap 
> Cc: Ian Jackson 
> Cc: Jan Beulich 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Stefano Stabellini 
> Cc: Tim Deegan 
> Cc: Wei Liu 
> Signed-off-by: Juergen Gross 

Reviewed-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v3 50/52] libxl: add libxl_set_parameters() function

[Wei Liu]

On Wed, Aug 16, 2017 at 02:52:17PM +0200, Juergen Gross wrote:
> Add a new libxl function to set hypervisor parameters at runtime
> similar to boot time parameters via command line.
> 
> Cc: Ian Jackson 
> Cc: Wei Liu 
> Signed-off-by: Juergen Gross 

Acked-by: Wei Liu 


> ---
> V2:
> - corrected coding style (Wei Liu)
> - removed superfluous #ifdef (Wei Liu)
> 
> V3:
> - use LOGEV() for error message
> ---
>  tools/libxl/libxl.c | 15 +++
>  tools/libxl/libxl.h |  8 
>  2 files changed, 23 insertions(+)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 0ef874406f..247c56cf83 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -652,6 +652,21 @@ int libxl_send_debug_keys(libxl_ctx *ctx, char *keys)
>  return 0;
>  }
>  
> +int libxl_set_parameters(libxl_ctx *ctx, char *params)
> +{
> +int ret;
> +GC_INIT(ctx);
> +
> +ret = xc_set_parameters(ctx->xch, params);
> +if (ret < 0) {
> +LOGEV(ERROR, ret, "setting parameters");
> +GC_FREE;
> +return ERROR_FAIL;
> +}

In case you repost, can you add a blank line here? Thanks.

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

Re: [Xen-devel] [PATCH v3 49/52] libxc: add function to set hypervisor parameters

[Wei Liu]

On Wed, Aug 16, 2017 at 02:52:16PM +0200, Juergen Gross wrote:
> Add a new libxc function to set hypervisor parameters at runtime
> similar to boot time parameters via command line.
> 
> Cc: Ian Jackson 
> Cc: Wei Liu 
> Signed-off-by: Juergen Gross 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH 09/27] xen/arm: traps: Don't define FAR_EL2 for ARM32

[Andre Przywara]

Hi,

On 14/08/17 15:24, Julien Grall wrote:
> Aliasing FAR_EL2 to HIFAR makes the code confusing because on ARMv8
> FAR_EL2[31:0] is architecturally mapped to HDFAR and FAR_EL2[63:32] to
> FAR_EL2.
  ^^^
I guess you mean HIFAR here.
Otherwise the patch makes sense.

> See D7.2.30 in ARM DDI 0487B.a. Open-code the alias instead.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Andre Przywara 

Cheers,
Andre.

> ---
>  xen/arch/arm/traps.c | 8 +++-
>  xen/include/asm-arm/cpregs.h | 1 -
>  2 files changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index c07999b518..498d8c594a 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -2560,11 +2560,17 @@ static void do_trap_instr_abort_guest(struct 
> cpu_user_regs *regs,
>const union hsr hsr)
>  {
>  int rc;
> -register_t gva = READ_SYSREG(FAR_EL2);
> +register_t gva;
>  uint8_t fsc = hsr.iabt.ifsc & ~FSC_LL_MASK;
>  paddr_t gpa;
>  mfn_t mfn;
>  
> +#ifdef CONFIG_ARM_32
> +gva = READ_CP32(HIFAR);
> +#else
> +gva = READ_SYSREG64(FAR_EL2);
> +#endif
> +
>  /*
>   * If this bit has been set, it means that this instruction abort is 
> caused
>   * by a guest external abort. We can handle this instruction abort as 
> guest
> diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
> index af45ec7a65..1889d7cbfb 100644
> --- a/xen/include/asm-arm/cpregs.h
> +++ b/xen/include/asm-arm/cpregs.h
> @@ -307,7 +307,6 @@
>  #define ESR_EL1 DFSR
>  #define ESR_EL2 HSR
>  #define FAR_EL1 HIFAR
> -#define FAR_EL2 HIFAR
>  #define HCR_EL2 HCR
>  #define HPFAR_EL2   HPFAR
>  #define HSTR_EL2HSTR
> 

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

Re: [Xen-devel] [PATCH v2 4/4] x86/dom0: re-order DMA remapping enabling for PVH Dom0

[Roger Pau Monne]

On Tue, Aug 22, 2017 at 06:37:15AM -0600, Jan Beulich wrote:
> >>> On 11.08.17 at 18:43,  wrote:
> > Make sure the reserved regions are setup before enabling the DMA
> > remapping in the IOMMU, by calling dom0_setup_permissions before
> > iommu_hwdom_init.
> 
> I can't match up this part with ...
> 
> > --- a/xen/arch/x86/hvm/dom0_build.c
> > +++ b/xen/arch/x86/hvm/dom0_build.c
> > @@ -605,13 +605,6 @@ static int __init pvh_setup_cpus(struct domain *d, 
> > paddr_t entry,
> >  return rc;
> >  }
> >  
> > -rc = dom0_setup_permissions(d);
> > -if ( rc )
> > -{
> > -panic("Unable to setup Dom0 permissions: %d\n", rc);
> > -return rc;
> > -}
> > -
> >  update_domain_wallclock_time(d);
> >  
> >  clear_bit(_VPF_down, >pause_flags);
> > @@ -1059,7 +1052,12 @@ int __init dom0_construct_pvh(struct domain *d, 
> > const module_t *image,
> >  
> >  printk("** Building a PVH Dom0 **\n");
> >  
> > -iommu_hwdom_init(d);
> > +rc = dom0_setup_permissions(d);
> > +if ( rc )
> > +{
> > +printk("Unable to setup Dom0 permissions: %d\n", rc);
> > +return rc;
> > +}
> >  
> >  rc = pvh_setup_p2m(d);
> >  if ( rc )
> > @@ -1068,6 +1066,8 @@ int __init dom0_construct_pvh(struct domain *d, const 
> > module_t *image,
> >  return rc;
> >  }
> >  
> > +iommu_hwdom_init(d);
> 
> ... you not changing the relative order between these two function
> calls. As to the other half I'm inclined to also wait for better
> understanding of what's going on here, as said in reply to patch 3.

Why not?

dom0_setup_permissions was called from pvh_setup_cpus, while
iommu_hwdom_init was the first function called in
dom0_construct_pvh.

After this patch dom0_setup_permissions is always called before
iommu_hwdom_init.

Roger.

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

Re: [Xen-devel] [PATCH v2 3/4] x86/vtd: introduce a PVH implementation of iommu_inclusive_mapping

[Roger Pau Monne]

On Tue, Aug 22, 2017 at 06:31:27AM -0600, Jan Beulich wrote:
> >>> On 11.08.17 at 18:43,  wrote:
> > On certain Intel systems, as far as I can tell almost all pre-Haswell ones,
> > trying to boot a PVH Dom0 will freeze the box completely, up to the point 
> > that
> > not even the watchdog works. The freeze happens exactly when enabling the 
> > DMA
> > remapping in the IOMMU, the last line seen is:
> > 
> > (XEN) [VT-D]iommu_enable_translation: iommu->reg = 82c00021b000
> > 
> > In order to workaround this (which seems to be a lack of proper RMRR 
> > entries,
> > plus the IOMMU being unable to generate faults and freezing the entire 
> > system)
> > add a PVH specific implementation of iommu_inclusive_mapping, that maps
> > non-RAM, non-unusable regions into Dom0 p2m. Note that care is taken to not 
> > map
> > device MMIO regions that Xen is emulating, like the local APIC or the IO 
> > APIC.
> > 
> > Signed-off-by: Roger Pau Monné 
> 
> I don't mean to object to the patch, but it certainly would be helpful
> to understand the behavior a little better, in particular also to
> perhaps be able to derive what RMRRs are missing (which could
> then be added via command line option instead of this all-or-norhing
> approach). Kevin, could you perhaps help here?

I tied that, but since the system freezes completely I have no idea
what's missing. It's quite clear to me that it's related to the IOMMU
and it's inability to properly generate a fault, but further than that
I have no other clue.

Roger.

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

Re: [Xen-devel] Xen 4.10 Development Update

[Meng Xu]

On Mon, Aug 21, 2017 at 6:07 AM, Julien Grall  wrote:
> 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

I'm moving the RTDS scheduler to work-conserving scheduler.
The first version of the patch series has been posted at
https://www.mail-archive.com/xen-devel@lists.xen.org/msg117062.html,
after we discussed the RFC patch.

Thanks,

Meng

-- 
---
Meng Xu
PhD Candidate in Computer and Information Science
University of Pennsylvania
http://www.cis.upenn.edu/~mengxu/

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

Re: [Xen-devel] [PATCH v2 1/4] x86/dom0: prevent access to MMCFG areas for PVH Dom0

[Roger Pau Monne]

On Tue, Aug 22, 2017 at 06:26:23AM -0600, Jan Beulich wrote:
> >>> On 11.08.17 at 18:43,  wrote:
> > They are emulated by Xen, so they must not be mapped into Dom0 p2m.
> > Introduce a helper function to add the MMCFG areas to the list of
> > denied iomem regions for PVH Dom0.
> 
> "They are" or "They are going to be"?

This started as a series on top of vPCI, but I think it has a chance
of getting in before vPCI. I will change it.

> > --- a/xen/arch/x86/dom0_build.c
> > +++ b/xen/arch/x86/dom0_build.c
> > @@ -440,6 +440,10 @@ int __init dom0_setup_permissions(struct domain *d)
> >  rc |= rangeset_add_singleton(mmio_ro_ranges, mfn);
> >  }
> >  
> > +/* For PVH prevent access to the MMCFG areas. */
> > +if ( dom0_pvh )
> > +rc |= pci_mmcfg_set_domain_permissions(d);
> 
> What about ones reported by Dom0 later on? Which then raises the
> question whether ...

This should be dealt with in the PHYSDEVOP_pci_mmcfg_reserved handler.
But since you propose to do white listing, I guess it doesn't matter
that much anymore.

> > @@ -175,6 +177,25 @@ void pci_mmcfg_arch_disable(unsigned int idx)
> > cfg->pci_segment, cfg->start_bus_number, cfg->end_bus_number);
> >  }
> >  
> > +int pci_mmcfg_set_domain_permissions(struct domain *d)
> > +{
> > +unsigned int idx;
> > +int rc = 0;
> > +
> > +for ( idx = 0; idx < pci_mmcfg_config_num; idx++ )
> > +{
> > +const struct acpi_mcfg_allocation *cfg = pci_mmcfg_virt[idx].cfg;
> > +unsigned long start = PFN_DOWN(cfg->address) +
> > +  PCI_BDF(cfg->start_bus_number, 0, 0);
> > +unsigned long end = PFN_DOWN(cfg->address) +
> > +PCI_BDF(cfg->end_bus_number, ~0, ~0);
> > +
> > +rc |= iomem_deny_access(d, start, end);
> 
> ... this shouldn't be unnecessary by, other than PV Dom0,
> starting out with no I/O memory being made accessible (i.e.
> white listing just like we decided we would do for other
> properties for PVH).

So would you like to switch to this white listing mode even for PV
Dom0, or just for PVH?

Should reserved regions and holes be added to it? Maybe only reserved
regions?

> Additionally while in the code that dom0_setup_permissions()
> was broken out from using |= was fine, there and here it's not
> really appropriate unless we want to continue to bake in the
> assumption that either iomem_deny_access() can only ever
> return a single error indicator or (b) the callers only care about
> the value being (non-)zero.

Right, I can fix that.

Thanks, Roger.

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

[Xen-devel] [linux-next test] 112778: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-credit2   6 xen-installfail pass in 112695
 test-armhf-armhf-xl-rtds 12 guest-startfail pass in 112695
 test-armhf-armhf-xl-vhd  16 guest-start.2  fail pass in 112695

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-win10-i386  1 build-check(1) blocked n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win10-i386  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-intel  1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 

Re: [Xen-devel] [PATCH V2 9/25] tools/libxl: build DMAR table for a guest with one virtual VTD

[Wei Liu]

On Fri, Aug 18, 2017 at 01:45:50PM +0800, Chao Gao wrote:
> On Thu, Aug 17, 2017 at 01:28:21PM +0100, Wei Liu wrote:
> >On Thu, Aug 17, 2017 at 12:32:17PM +0100, Wei Liu wrote:
> >> On Wed, Aug 09, 2017 at 04:34:10PM -0400, Lan Tianyu wrote:
> >> > diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> >> > index f54fd49..94c9196 100644
> >> > --- a/tools/libxl/libxl_dom.c
> >> > +++ b/tools/libxl/libxl_dom.c
> >> > @@ -1060,6 +1060,42 @@ static int libxl__domain_firmware(libxl__gc *gc,
> >> >  }
> >> >  }
> >> >  
> >> > +/*
> >> > + * If a guest has one virtual VTD, build DMAR table for it and 
> >> > joint this
> >> > + * table with existing content in acpi_modules in order to employ 
> >> > HVM
> >> > + * firmware pass-through mechanism to pass-through DMAR table.
> >> > + */
> >> > +if (info->viommu.type == LIBXL_VIOMMU_TYPE_INTEL_VTD) {
> >> > +datalen = 0;
> >> > +e = libxl__dom_build_dmar(gc, info, dom, , );
> >> > +if (e) {
> >> > +LOGEV(ERROR, e, "failed to build DMAR table");
> >> > +rc = ERROR_FAIL;
> >> > +goto out;
> >> > +}
> >> > +if (datalen) {
> >> > +libxl__ptr_add(gc, data);
> >> > +if (!dom->acpi_modules[0].data) {
> >> > +dom->acpi_modules[0].data = data;
> >> > +dom->acpi_modules[0].length = (uint32_t)datalen;
> >> > +} else {
> >> > +/* joint tables */
> >> > +void *newdata;
> >> > +newdata = malloc(datalen + dom->acpi_modules[0].length);
> >> 
> >> All memory allocations in libxl should use libxl__*lloc wrappers.
> >> 
> >> > +if (!newdata) {
> >> > +LOGE(ERROR, "failed to joint DMAR table to acpi 
> >> > modules");
> >> > +rc = ERROR_FAIL;
> >> > +goto out;
> >> > +}
> >> > +memcpy(newdata, dom->acpi_modules[0].data,
> >> > +   dom->acpi_modules[0].length);
> >> > +memcpy(newdata + dom->acpi_modules[0].length, data, 
> >> > datalen);
> >> > +dom->acpi_modules[0].data = newdata;
> >> > +dom->acpi_modules[0].length += (uint32_t)datalen;
> >
> >Also, this leaks the old pointer, right?
> 
> Yes. Will fix this.
> 
> >
> >> > +}
> >> > +}
> >> > +}
> >> 
> >> This still looks wrong to me. How do you know acpi_modules[0] is DMAR
> >> table?
> >> 
> >
> >Oh, I sorta see why you do this, but I still think this is wrong. The
> >DMAR should either be a new module or be joined to the existing one (and
> >with all conflicts resolved).
> 
> Hi, Wei
> Thanks for your comments.
> 
> iirc, HVM only supports one module; DMAR cannot be a new module. Joining to
> the existing one is the approach we are taking. 
> 
> Which kind of conflicts you think should be resolved? If you mean I
> forget to free the old buf, I will fix this. If you mean the potential
> overlap between the binary passed by admin and DMAR table built here, I
> don't have much idea on this. Even without the DMAR table, the binary
> may contains MADT or other tables and tool stacks don't intrepret the
> binary and check whether there are conflicts, right?
> 

Thinking a bit more about this, when I first said "conflicts" I didn't
mean to parse the content. I was referring to the code in
libxl_x86_apci.c which also seems to manipulate acpi_modules.

I would like the code to generate dmar take into consideration
libxl__dom_load_acpi.


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

Re: [Xen-devel] [PATCH V2 9/25] tools/libxl: build DMAR table for a guest with one virtual VTD

[Wei Liu]

On Fri, Aug 18, 2017 at 07:56:36AM -0600, Jan Beulich wrote:
> >>> On 18.08.17 at 15:45,  wrote:
> > On Fri, Aug 18, 2017 at 01:45:50PM +0800, Chao Gao wrote:
> >> >
> >> >> > +}
> >> >> > +}
> >> >> > +}
> >> >> 
> >> >> This still looks wrong to me. How do you know acpi_modules[0] is DMAR
> >> >> table?
> >> >> 
> >> >
> >> >Oh, I sorta see why you do this, but I still think this is wrong. The
> >> >DMAR should either be a new module or be joined to the existing one (and
> >> >with all conflicts resolved).
> >> 
> >> Hi, Wei
> >> Thanks for your comments.
> >> 
> >> iirc, HVM only supports one module;
> > 
> > This is indeed how it is stated in various comments. I'm not sure why
> > there is such restriction. Maybe x86 maintainers can shed more light on
> > this?
> 
> Not me, sorry. Maybe ask whoever has written that code?
> 

OK. I have misunderstood the restriction was from hvmloader.

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

Re: [Xen-devel] [PATCH V2 8/25] tools/libxl: Add a user configurable parameter to control vIOMMU attributes

[Wei Liu]

On Wed, Aug 09, 2017 at 04:34:09PM -0400, Lan Tianyu wrote:
> From: Chao Gao 
[...]
> -=back 
> +=back
> +
> +=item