[Xen-devel] [linux-arm-xen test] 33699: tolerable FAIL - PUSHED

[xen . org]

flight 33699 linux-arm-xen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33699/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt  9 guest-start  fail   never pass
 test-armhf-armhf-xl  10 migrate-support-checkfail   never pass

version targeted for testing:
 linuxec18c9fc039971041d854e0d58551f1f1a32ff8f
baseline version:
 linux780a61e9af6d5634897feabd0f1cb3fecea41590


People who touched revisions under test:
  Ian Campbell 
  Konrad Rzeszutek Wilk 
  Luis Henriques 
  Stefano Stabellini 


jobs:
 build-armhf  pass
 build-armhf-libvirt  pass
 build-armhf-pvopspass
 test-armhf-armhf-xl  pass
 test-armhf-armhf-libvirt fail



sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
http://www.chiark.greenend.org.uk/~xensrcts/logs

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


Pushing revision :

+ branch=linux-arm-xen
+ revision=ec18c9fc039971041d854e0d58551f1f1a32ff8f
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push linux-arm-xen 
ec18c9fc039971041d854e0d58551f1f1a32ff8f
+ branch=linux-arm-xen
+ revision=ec18c9fc039971041d854e0d58551f1f1a32ff8f
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock 
']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=linux
+ xenbranch=xen-unstable
+ '[' xlinux = xlinux ']'
+ linuxbranch=linux-arm-xen
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osst...@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 
'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 
'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osst...@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git = x 
']'
++ '[' xgit://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git = x 
']'
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git

Re: [Xen-devel] Difference between normal Dom0 and PVH Dom0

[openlui]

Thanks for you relay, Konrad. 

At 2015-01-23 22:29:48, "Konrad Rzeszutek Wilk"  wrote:
>On Fri, Jan 23, 2015 at 03:54:07PM +0800, openlui wrote:
>> Hi,  all:
>> From the article [1] and xen-colors picture from Brendan Gergg's blog 
>> [2], I have some understanding and question about PVH Dom0 as follows:
>> 1. Even after pvops has been support in Linux mainline kernel, current 
>> XEN dom0 is still a "Full PV" domain (I will call it as "normal Dom0" in 
>> this mail), am I right?
>

>It can do both.
Currently, PVH dom0 is still under development. I find it is announced as an 
experimental feature for XEN 4.5.


>> 2. The normal Dom0 cannot take advantage of the Hardware visualization 
>> extensions like HVM Domain, including privileged instructions and 
>> pagetables. I am wondering how much performance impact it will have compared 
>> with PVH and HVM Domain, and does it means that the technology such as 
>> shadow page table is needed for Dom0?
>

>It is less faster than PVH.


Without the assistance of hardware visualization extensions, what are the 
"para-visualization ways" for handling the pagetables or privileged 
instructions?  Hypercall for privileged instructions and Shadow page table for 
pagetables?
>
>> 3. For the normal Dom0 running with x86_64, because of the elimination 
>> of segmentation limit, each system call in Dom0 will bounce up into Xen and 
>> then context-switch to the Dom0 kernel, and will cause frequent flushing of 
>> the TLB. Is this also applied to  x86_64 cpus from other vendors other than 
>> AMD? How can I verify it? It seems that the problem will have big impact for 
>> Dom0 performance, does it?
>
>It does have - however Linux has made strides in minimizing the need for 
>making TLB flushes and
>also the major reason for doing up-calls is batched to minimize the amount the 
>frequent usage of TLB flushes.

I am wondering why frequent flushing of the TLB will be caused when each system 
call in Dom0 bounces up into Xen and then context-switch to the Dom0 kernel. 
Could you give me some hint?


>> 4. PVH Dom0 can improve the maintainability of pvops related code of Xen 
>> as well as improve the performance of normal Dom0. I am wondering if there 
>> are other aspects of performance PVH Dom0 can improve besides the 2 and 3 
>> mentioned above.
>
>Yes. We can use compound pages without the SWIOTLB finding the pages not being 
>contingous. That
>will improve network performance.

I don't have more experience about SWIOTLB and compound pages you mentioned 
above, could you give me some more info or some reference about them? 
>> 
>> [1] 
>> https://blog.xenproject.org/2012/10/31/the-paravirtualization-spectrum-part-2-from-poles-to-a-spectrum/
>> [2] http://www.brendangregg.com/blog/images/2014/xen-colors.png
>
>> ___
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>
>
>___
>Xen-devel mailing list
>Xen-devel@lists.xen.org
>http://lists.xen.org/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCHv2 net-next] xen-netback: always fully coalesce guest Rx packets

[David Miller]

From: David Vrabel 
Date: Tue, 20 Jan 2015 14:49:52 +

> Always fully coalesce guest Rx packets into the minimum number of ring
> slots.  Reducing the number of slots per packet has significant
> performance benefits when receiving off-host traffic.
> 
> Results from XenServer's performance benchmarks:
> 
>  BaselineFull coalesce
> Interhost VM receive  7.2 Gb/s   11 Gb/s
> Interhost aggregate  24 Gb/s 24 Gb/s
> Intrahost single stream  14 Gb/s 14 Gb/s
> Intrahost aggregate  34 Gb/s 34 Gb/s
> 
> However, this can increase the number of grant ops per packet which
> decreases performance of backend (dom0) to VM traffic (by ~10%)
> /unless/ grant copy has been optimized for adjacent ops with the same
> source or destination (see "grant-table: defer releasing pages
> acquired in a grant copy"[1] expected in Xen 4.6).
> 
> [1] http://lists.xen.org/archives/html/xen-devel/2015-01/msg01118.html
> 
> Signed-off-by: David Vrabel 
> Acked-by: Ian Campbell 
> ---
> Changes in v2:
> - Updated commit message with better results.

Applied, thanks David.

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

[Xen-devel] [linux-next test] 33677: regressions - FAIL

[xen . org]

flight 33677 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33677/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rumpuserxen-i386  5 xen-boot  fail REGR. vs. 33611
 test-armhf-armhf-xl   5 xen-boot  fail REGR. vs. 33611
 test-armhf-armhf-libvirt  5 xen-boot  fail REGR. vs. 33611
 test-amd64-i386-xl-multivcpu  9 guest-start   fail REGR. vs. 33611
 test-amd64-i386-xl-credit29 guest-start   fail REGR. vs. 33611
 test-amd64-i386-xl-qemut-winxpsp3  5 xen-boot fail REGR. vs. 33611
 test-amd64-i386-xl9 guest-start   fail REGR. vs. 33611
 test-amd64-i386-pair 16 guest-start/debianfail REGR. vs. 33611
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install fail REGR. vs. 33611

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-freebsd10-amd64  7 freebsd-install fail like 33611
 test-amd64-i386-freebsd10-i386  7 freebsd-install  fail like 33611
 test-amd64-amd64-xl-pcipt-intel  7 debian-install fail REGR. vs. 33611
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install  fail like 33611

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start  fail  never pass
 test-amd64-i386-libvirt   9 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-amd   9 guest-start  fail   never pass
 test-amd64-amd64-libvirt  9 guest-start  fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop  fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop   fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop   fail  never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop   fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stopfail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop   fail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass

version targeted for testing:
 linuxab36bc62df3bdb79b3468ecabd11289cd399bdb1
baseline version:
 linuxb97f880c8342fd6e49a02c9ef7507a678722b2b3

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  pass
 build-i386-rumpuserxen   pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  fail
 test-amd64-i386-xl   fail
 test-amd64-amd64-xl-pvh-amd  fail
 test-amd64-i386-rhel6hvm-amd pass
 test-amd64-i386-qemut-rhel6hvm-amd   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64pass
 test-amd64-i386-xl-qemut-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  fail
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-rumpuserxen-amd64   pass
 test-amd64-amd64-xl-qemut-win7-amd64 fail
 test-amd64-i386-xl-qemut-win7-amd64  fail
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-win7-amd64   

[Xen-devel] libvirt domXML -> libxl_domain_config conversion testing

[Jim Fehlig]

Hi All,

I've been attempting to revive the libvirt domXML -> libxl_domain_config
tests originally started by Daniel all the way back in May!

https://www.redhat.com/archives/libvir-list/2014-May/msg01102.html

In a reply to patch5 of the series, Ian Campbell noted that the doc
produced by libxl_domain_config_to_json() may change as new config is
added, defaults changed, etc.  Some suggestions for coping with this
included

1. json template files per libxl version

2. a new API in libvirt's json toolbox to compare json docs (with ability
   to control the comparison, e.g. ignore certain content)

3. make use of new functionality in Xen 4.5 such as
   libxl_domain_config_from_json() and libxl_domain_config_compare()

Option 1 is simple-minded.

Option 2 is an improvement, but a growing list of content must be
ignored as additions/changes are made to the libxl_domain_config
object.  (Example of ignored content in this discussion -
https://www.redhat.com/archives/libvir-list/2014-September/msg00627.html). 
In some cases, we might actually want to test some of the new content
instead of ignoring it.

Option 3 is promising, but doesn't help with Xen versions 4.2-4.4. 
Also, 4.5 is missing libxl_domain_config_compare().

After a bit of hacking on a combination of 2 and 3, I'm reconsidering 1
:-).  At least for Xen 4.2-4.5.  It's a simple solution that doesn't
prevent testing new content in the libxl_domain_config object.  Going
forward, I could work on libxl_domain_config_compare() for
xen-unstable/4.6, and then use option 3 to stop the template bloom.

Any thoughts on this approach?  Smarter options?

Regards,
Jim

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

Re: [Xen-devel] [PATCH v1 13/21] Ovmf/Xen: move arch specific hypercall implementation to XenHypercallLib

[Laszlo Ersek]

On 01/23/15 19:24, Stefano Stabellini wrote:
> On Fri, 23 Jan 2015, Ard Biesheuvel wrote:
>> For future ARM/AArch64 support in the XenBus code, move the implementation
>> of hypercall invocation to a dedicated library. The use of a library rather
>> than just an arch specific source in XenBusDxe.inf allows us to move the
>> constructor dependency on the gXenInfoGuid HOB to the library implementation.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Ard Biesheuvel 
> 
> Although it looks vaguely OK, I think it would be much more readable if
> you broke this patch down, separating out the code movements from the
> changes to the interface (like dropping the XENBUS_DEVICE* parameter).

If that's possible, then I second the motion.

Thanks
Laszlo


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

Re: [Xen-devel] [PATCH v1 12/21] Ovmf/Xen: fix pointer to int cast in XenBusDxe

[Laszlo Ersek]

On 01/23/15 16:03, Ard Biesheuvel wrote:
> On ARM, xen_pfn_t is 64 bits but the size of a pointer is only
> 32 bits, so casting between them needs to go via (UINTN)
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
>  OvmfPkg/XenBusDxe/GrantTable.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/OvmfPkg/XenBusDxe/GrantTable.c b/OvmfPkg/XenBusDxe/GrantTable.c
> index 37d3bf786c64..cc6f045c9827 100644
> --- a/OvmfPkg/XenBusDxe/GrantTable.c
> +++ b/OvmfPkg/XenBusDxe/GrantTable.c
> @@ -160,7 +160,7 @@ XenGrantTableInit (
>  Parameters.domid = DOMID_SELF;
>  Parameters.idx = Index;
>  Parameters.space = XENMAPSPACE_grant_table;
> -Parameters.gpfn = (((xen_pfn_t) GrantTable) >> EFI_PAGE_SHIFT) + Index;
> +Parameters.gpfn = (((xen_pfn_t)(UINTN) GrantTable) >> EFI_PAGE_SHIFT) + 
> Index;
>  ReturnCode = XenHypercallMemoryOp (Dev, XENMEM_add_to_physmap, 
> &Parameters);
>  if (ReturnCode != 0) {
>DEBUG ((EFI_D_ERROR, "Xen GrantTable, add_to_physmap hypercall error: 
> %d\n", ReturnCode));
> @@ -182,7 +182,7 @@ XenGrantTableDeinit (
>  
>for (Index = NR_GRANT_FRAMES - 1; Index >= 0; Index--) {
>  Parameters.domid = DOMID_SELF;
> -Parameters.gpfn = (((xen_pfn_t) GrantTable) >> EFI_PAGE_SHIFT) + Index;
> +Parameters.gpfn = (((xen_pfn_t)(UINTN) GrantTable) >> EFI_PAGE_SHIFT) + 
> Index;
>  DEBUG ((EFI_D_INFO, "Xen GrantTable, removing %X\n", Parameters.gpfn));
>  ReturnCode = XenHypercallMemoryOp (Dev, XENMEM_remove_from_physmap, 
> &Parameters);
>  if (ReturnCode != 0) {
> 

On a 32-bit platform you shouldn't bit-shift 64-bit integers, because
the compiler might generate calls to intrinsic functions, and those are
not allowed in edk2.

Please use RShiftU64() in addition to the above changes.

(Example: "MdePkg/Library/BaseLib/Ia32/RShiftU64.S".)

Thanks,
Laszlo

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

[Xen-devel] [ovmf baseline test] 33686: tolerable FAIL

[xen . org]

"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate.  The baseline, if
any, is the most recent actually tested revision.

flight 33686 ovmf real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33686/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt  9 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel  9 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd   9 guest-start  fail   never pass
 test-amd64-amd64-xl-sedf-pin 15 guest-localmigrate/x10   fail   never pass
 test-amd64-i386-libvirt   9 guest-start  fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop   fail  never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop  fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop   fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stopfail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop   fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install  fail never pass

version targeted for testing:
 ovmf 447d264115c476142f884af0be287622cd244423
baseline version:
 ovmf 447d264115c476142f884af0be287622cd244423

jobs:
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-xl-pvh-amd  fail
 test-amd64-i386-rhel6hvm-amd pass
 test-amd64-i386-qemut-rhel6hvm-amd   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64pass
 test-amd64-i386-xl-qemut-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-xl-qemut-win7-amd64 fail
 test-amd64-i386-xl-qemut-win7-amd64  fail
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-win7-amd64   fail
 test-amd64-i386-xl-win7-amd64fail
 test-amd64-i386-xl-credit2   pass
 test-amd64-i386-freebsd10-i386   pass
 test-amd64-amd64-xl-pcipt-intel  fail
 test-amd64-amd64-xl-pvh-intelfail
 test-amd64-i386-rhel6hvm-intel   pass
 test-amd64-i386-qemut-rhel6hvm-intel pass
 test-amd64-i386-qemuu-rhel6hvm-intel pass
 test-amd64-amd64-libvirt fail
 test-amd64-i386-libvirt  fail
 test-amd64-i386-xl-multivcpu pass
 test-amd64-amd64-pairpass
 test-amd64-i386-pair pass
 test-amd64-amd64-xl-sedf-pin fail
 test-amd64-amd64-xl-sedf pass
 test-amd6

Re: [Xen-devel] [PATCH v1 11/21] Ovmf/Xen: move Xen interface version to

[Laszlo Ersek]

On 01/23/15 16:03, Ard Biesheuvel wrote:
> Tiancore has its private copy of the Xen headers, and all drivers
> that depend on it should use the same Xen interface version, so
> let's move the #define to xen.h itself.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
>  OvmfPkg/Include/IndustryStandard/Xen/xen.h | 5 +
>  OvmfPkg/XenBusDxe/XenBusDxe.h  | 5 -
>  OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.h  | 4 
>  3 files changed, 5 insertions(+), 9 deletions(-)
> 
> diff --git a/OvmfPkg/Include/IndustryStandard/Xen/xen.h 
> b/OvmfPkg/Include/IndustryStandard/Xen/xen.h
> index 79697fcb6152..1cd7ab3ab136 100644
> --- a/OvmfPkg/Include/IndustryStandard/Xen/xen.h
> +++ b/OvmfPkg/Include/IndustryStandard/Xen/xen.h
> @@ -27,6 +27,11 @@
>  #ifndef __XEN_PUBLIC_XEN_H__
>  #define __XEN_PUBLIC_XEN_H__
>  
> +//
> +// Xen interface version used by Tianocore
> +//
> +#define __XEN_INTERFACE_VERSION__ 0x00040400
> +
>  #include "xen-compat.h"
>  
>  #if defined(MDE_CPU_IA32) || defined(MDE_CPU_X64)
> diff --git a/OvmfPkg/XenBusDxe/XenBusDxe.h b/OvmfPkg/XenBusDxe/XenBusDxe.h
> index 11640223ebf4..80253b7d1ca9 100644
> --- a/OvmfPkg/XenBusDxe/XenBusDxe.h
> +++ b/OvmfPkg/XenBusDxe/XenBusDxe.h
> @@ -19,11 +19,6 @@
>  #include 
>  
>  //
> -// Xen interface version used
> -//
> -#define  __XEN_INTERFACE_VERSION__ 0x00040400
> -
> -//
>  // Libraries
>  //
>  #include 
> diff --git a/OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.h 
> b/OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.h
> index e5b1b5f4b90d..c0b62c4f38ca 100644
> --- a/OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.h
> +++ b/OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.h
> @@ -18,10 +18,6 @@
>  
>  #include 
>  
> -//
> -// Xen interface version used
> -//
> -#define __XEN_INTERFACE_VERSION__ 0x00040400
>  #define xen_mb() MemoryFence()
>  #define xen_rmb() MemoryFence()
>  #define xen_wmb() MemoryFence()
> 

Acked-by: Laszlo Ersek 

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

Re: [Xen-devel] [PATCH v1 06/21] ArmVirtualizationPkg: add padding to FDT allocation

[Laszlo Ersek]

On 01/23/15 16:02, Ard Biesheuvel wrote:
> Our primary user QEMU/mach-virt presents us with a FDT blob padded
> to 64 KB with plenty of room to set additional properties. However,
> in the general case, we should only add properties after making sure
> there is enough room available.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
>  .../Library/PlatformPeiLib/PlatformPeiLib.c | 17 
> +
>  1 file changed, 13 insertions(+), 4 deletions(-)
> 
> diff --git 
> a/ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformPeiLib/PlatformPeiLib.c 
> b/ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformPeiLib/PlatformPeiLib.c
> index f2404f89d152..540474608deb 100644
> --- 
> a/ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformPeiLib/PlatformPeiLib.c
> +++ 
> b/ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformPeiLib/PlatformPeiLib.c
> @@ -24,6 +24,15 @@
>  #include 
>  #include 
>  
> +//
> +// We may want to apply some changes to the device tree before passing it
> +// to the OS: for instance, if we find a PL031 RTC node and attach our
> +// runtime driver to it, we should disable it in the device tree by setting
> +// its status property to "disabled". Add some padding to make sure this is
> +// possible.
> +//
> +#define FDT_PADDING   256
> +
>  EFI_STATUS
>  EFIAPI
>  PlatformPeim (
> @@ -32,7 +41,7 @@ PlatformPeim (
>  {
>VOID   *Base;
>VOID   *NewBase;
> -  UINTN  FdtSize;
> +  UINTN  FdtPages;
>UINTN  *FdtHobData;
>UINT64 *UartHobData;
>INT32  Node, Prev;
> @@ -46,10 +55,10 @@ PlatformPeim (
>Base = (VOID*)(UINTN)PcdGet64 (PcdDeviceTreeInitialBaseAddress);
>ASSERT (Base != NULL && fdt_check_header (Base) == 0);
>  
> -  FdtSize = fdt_totalsize (Base);
> -  NewBase = AllocatePages (EFI_SIZE_TO_PAGES (FdtSize));
> +  FdtPages = EFI_SIZE_TO_PAGES (fdt_totalsize (Base) + FDT_PADDING);
> +  NewBase = AllocatePages (FdtPages);
>ASSERT (NewBase != NULL);
> -  CopyMem (NewBase, Base, FdtSize);
> +  fdt_open_into (Base, NewBase, EFI_PAGES_TO_SIZE (FdtPages));
>  
>FdtHobData = BuildGuidHob (&gFdtHobGuid, sizeof *FdtHobData);
>ASSERT (FdtHobData != NULL);
> 

One nit: please keep the original FdtSize assignment (with type UINTN)
and use that inside the EFI_SIZE_TO_PAGES() expression, when calculating
FdtPages.

Two reasons:
- EFI_SIZE_TO_PAGES evaluates its argument twice. Although
  fdt_totalsize() is r/o and probably quick even, it's not very nice to
  call it twice.
- I tried to figure out the return type of fdt_totalsize(), but I gave
  up quickly after looking at the header file. However,
  EFI_SIZE_TO_PAGES() should strictly take UINTN, which FdtSize covers
  at once.

Sth like:

  FdtSize = fdt_totalsize (Base) + FDT_PADDING;
  FdtPages = EFI_SIZE_TO_PAGES (FdtSize);
  NewBase = AllocatePages (FdtPages);
  ...
  fdt_open_into (Base, NewBase, EFI_PAGES_TO_SIZE (FdtPages));

Thanks
Laszlo

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

Re: [Xen-devel] [PATCH v3 0/3] arm: introduce basic Renesas R-Car Gen2 platform support

[Oleksandr Tyshchenko]

24 янв. 2015 г. 0:36 пользователь "Julien Grall" 
написал:
>
> Hi Oleksandr,
>
Hi Julien
>
> On 23/01/2015 15:33, Oleksandr Tyshchenko wrote:
>>
>> Changes in v3:
>> 1. Rewrite uart driver code to use start_tx/stop_tx callbacks.
>> 2. Uncomment udelay after setup desired baudrate.
>
>
> It might be worse to mention that this series depend on
> http://www.gossamer-threads.com/lists/xen/devel/363758
>
I think yes, by default we do not change baudrate, so the driver does not
call udelay.

> Although, it's only in order to run Xen on R-Car 2.
>
> Regards,
>
> --
> Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 2/3] xen/arm: Add new driver for R-Car Gen2 UART

[Julien Grall]

Hi Oleksandr,

On 23/01/2015 15:33, Oleksandr Tyshchenko wrote:

Signed-off-by: Oleksandr Tyshchenko 
Signed-off-by: Iurii Konovalenko 
CC: Julien Grall 


Reviewed-by: Julien Grall 

Regards,


---
  config/arm32.mk   |   1 +
  xen/drivers/char/Makefile |   1 +
  xen/drivers/char/rcar2-uart.c | 366 ++
  3 files changed, 368 insertions(+)
  create mode 100644 xen/drivers/char/rcar2-uart.c

diff --git a/config/arm32.mk b/config/arm32.mk
index 4f83a63..6ee5173 100644
--- a/config/arm32.mk
+++ b/config/arm32.mk
@@ -12,6 +12,7 @@ CFLAGS += -marm
  HAS_PL011 := y
  HAS_EXYNOS4210 := y
  HAS_OMAP := y
+HAS_RCAR2 := y
  HAS_NS16550 := y

  # Use only if calling $(LD) directly.
diff --git a/xen/drivers/char/Makefile b/xen/drivers/char/Makefile
index 911b788..64428b7 100644
--- a/xen/drivers/char/Makefile
+++ b/xen/drivers/char/Makefile
@@ -3,6 +3,7 @@ obj-$(HAS_NS16550) += ns16550.o
  obj-$(HAS_PL011) += pl011.o
  obj-$(HAS_EXYNOS4210) += exynos4210-uart.o
  obj-$(HAS_OMAP) += omap-uart.o
+obj-$(HAS_RCAR2) += rcar2-uart.o
  obj-$(HAS_EHCI) += ehci-dbgp.o
  obj-$(CONFIG_ARM) += dt-uart.o
  obj-y += serial.o
diff --git a/xen/drivers/char/rcar2-uart.c b/xen/drivers/char/rcar2-uart.c
new file mode 100644
index 000..7ace6ad
--- /dev/null
+++ b/xen/drivers/char/rcar2-uart.c
@@ -0,0 +1,366 @@
+/*
+ * xen/drivers/char/rcar2-uart.c
+ *
+ * Driver for R-Car Gen2 UART.
+ *
+ * Oleksandr Tyshchenko 
+ * Copyright (C) 2014, Globallogic.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define PARITY_NONE0
+#define PARITY_EVEN1
+#define PARITY_ODD 2
+
+#define rcar2_readb(uart, off)  readb((uart)->regs + (off))
+#define rcar2_writeb(uart, off, val)writeb((val), (uart)->regs + (off))
+
+#define rcar2_readw(uart, off)  readw((uart)->regs + (off))
+#define rcar2_writew(uart, off, val)writew((val), (uart)->regs + (off))
+
+static struct rcar2_uart {
+unsigned int baud, clock_hz, data_bits, parity, stop_bits;
+unsigned int irq;
+char __iomem *regs;
+struct irqaction irqaction;
+struct vuart_info vuart;
+} rcar2_com = {0};
+
+static void rcar2_uart_interrupt(int irq, void *data, struct cpu_user_regs 
*regs)
+{
+struct serial_port *port = data;
+struct rcar2_uart *uart = port->uart;
+uint16_t status, ctrl;
+
+ctrl = rcar2_readw(uart, SCIF_SCSCR);
+status = rcar2_readw(uart, SCIF_SCFSR) & ~SCFSR_TEND;
+/* Ignore next flag if TX Interrupt is disabled */
+if ( !(ctrl & SCSCR_TIE) )
+status &= ~SCFSR_TDFE;
+
+while ( status != 0 )
+{
+/* TX Interrupt */
+if ( status & SCFSR_TDFE )
+serial_tx_interrupt(port, regs);
+
+/* RX Interrupt */
+if ( status & (SCFSR_RDF | SCFSR_DR) )
+serial_rx_interrupt(port, regs);
+
+/* Error Interrupt */
+if ( status & SCIF_ERRORS )
+rcar2_writew(uart, SCIF_SCFSR, ~SCIF_ERRORS);
+if ( rcar2_readw(uart, SCIF_SCLSR) & SCLSR_ORER )
+rcar2_writew(uart, SCIF_SCLSR, 0);
+
+ctrl = rcar2_readw(uart, SCIF_SCSCR);
+status = rcar2_readw(uart, SCIF_SCFSR) & ~SCFSR_TEND;
+/* Ignore next flag if TX Interrupt is disabled */
+if ( !(ctrl & SCSCR_TIE) )
+status &= ~SCFSR_TDFE;
+}
+}
+
+static void __init rcar2_uart_init_preirq(struct serial_port *port)
+{
+struct rcar2_uart *uart = port->uart;
+unsigned int divisor;
+uint16_t val;
+
+/*
+ * Wait until last bit has been transmitted. This is needed for a smooth
+ * transition when we come from early printk
+ */
+while ( !(rcar2_readw(uart, SCIF_SCFSR) & SCFSR_TEND) );
+
+/* Disable TX/RX parts and all interrupts */
+rcar2_writew(uart, SCIF_SCSCR, 0);
+
+/* Reset TX/RX FIFOs */
+rcar2_writew(uart, SCIF_SCFCR, SCFCR_RFRST | SCFCR_TFRST);
+
+/* Clear all errors and flags */
+rcar2_readw(uart, SCIF_SCFSR);
+rcar2_writew(uart, SCIF_SCFSR, 0);
+rcar2_readw(uart, SCIF_SCLSR);
+rcar2_writew(uart, SCIF_SCLSR, 0);
+
+/* Select Baud rate generator output as a clock source */
+rcar2_writew(uart, SCIF_SCSCR, SCSCR_CKE10);
+
+/* Setup protocol format and Baud rate, select Asynchronous mode */
+val = 0;
+ASSERT( uart->data_bits >= 7 && uart->data_bits <= 8 );
+if ( uart->data_bits == 7 )
+val |= SCSMR_CH

Re: [Xen-devel] [PATCH v3 0/3] arm: introduce basic Renesas R-Car Gen2 platform support

[Julien Grall]

Hi Oleksandr,

On 23/01/2015 15:33, Oleksandr Tyshchenko wrote:

Changes in v3:
1. Rewrite uart driver code to use start_tx/stop_tx callbacks.
2. Uncomment udelay after setup desired baudrate.


It might be worse to mention that this series depend on
http://www.gossamer-threads.com/lists/xen/devel/363758

Although, it's only in order to run Xen on R-Car 2.

Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v1 10/21] ArmVirtualizationPkg: Xen/PV relocatable platformlib instance

[Laszlo Ersek]

On 01/23/15 16:02, Ard Biesheuvel wrote:
> Add a ArmPlatformLib instance that can deal with the self relocation
> and truly dynamic discovery of system RAM base and size.
> 
> Signed-off-by: Ard Biesheuvel 
> ---
>  .../AARCH64/MemnodeParser.S| 232 
> +
>  .../AARCH64/RelocatableVirtHelper.S| 161 ++
>  .../ArmXenRelocatablePlatformLib.inf   |  66 ++
>  .../ArmVirtualizationPlatformLib/RelocatableVirt.c |  78 +++
>  .../ArmVirtualizationPlatformLib/XenVirtMem.c  |  83 
>  5 files changed, 620 insertions(+)
>  create mode 100644 
> ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/AARCH64/MemnodeParser.S
>  create mode 100644 
> ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/AARCH64/RelocatableVirtHelper.S
>  create mode 100644 
> ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/ArmXenRelocatablePlatformLib.inf
>  create mode 100644 
> ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/RelocatableVirt.c
>  create mode 100644 
> ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/XenVirtMem.c

Please do not add these new files to the existent directory

ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/

because the new files will mix with the old and they will crash my brain
when I need to look at them two weeks later.

You're adding a full-blown, standalone library instance of
ArmPlatformLib, called "ArmVirtRelocatablePlatformLib" (see BASE_NAME in
the new INF file); please introduce it in a separate directory:

ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtRelocatablePlatformLib

The general rule is: one INF file per directory, unless you build the
library for different UEFI phases, and some of the .c files are shared
between them (ie. some .c files with library logic are included by
multiple phases / multiple INF files). That's not the case here; please
keep 'em separated.

Thanks!
Laszlo


> 
> diff --git 
> a/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/AARCH64/MemnodeParser.S
>  
> b/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/AARCH64/MemnodeParser.S
> new file mode 100644
> index ..cce2c4800c51
> --- /dev/null
> +++ 
> b/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/AARCH64/MemnodeParser.S
> @@ -0,0 +1,232 @@
> +/*
> + * Copyright (c) 2014, Linaro Ltd. All rights reserved.
> + *
> + * This program and the accompanying materials
> + * are licensed and made available under the terms and conditions of the BSD 
> License
> + * which accompanies this distribution.  The full text of the license may be 
> found at
> + * http://opensource.org/licenses/bsd-license.php
> + *
> + * THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> + * WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
> IMPLIED.
> + */
> +
> +/*
> + * Theory of operation
> + * ---
> + *
> + * This code parses a Flattened Device Tree binary (DTB) to find the base of
> + * system RAM. It is written in assembly so that it can be executed before a
> + * stack has been set up.
> + *
> + * To find the base of system RAM, we have to traverse the FDT to find a 
> memory
> + * node. In the context of this implementation, the first node that has a
> + * device_type property with the value 'memory' and a 'reg' property is
> + * acceptable, and the name of the node (memory[@xxx]) is ignored, as are any
> + * other nodes that match the above constraints.
> + *
> + * In pseudo code, this implementation does the following:
> + *
> + * for each node {
> + *   have_device_type = false
> + *   have_reg = false
> + *
> + *   for each property {
> + *   if property value == 'memory' {
> + *   if property name == 'device_type' {
> + *   have_device_type = true
> + *   }
> + *   } else {
> + *   if property name == 'reg' {
> + *   have_reg = true
> + *   membase = property value[0]
> + *   memsize = property value[1]
> + *   }
> + *   }
> + *   }
> + *   if have_device_type and have_reg {
> + *   return membase and memsize
> + *   }
> + * }
> + * return NOT_FOUND
> + */
> +
> +#define FDT_MAGIC0xedfe0dd0
> +
> +#define FDT_BEGIN_NODE   0x1
> +#define FDT_END_NODE 0x2
> +#define FDT_PROP 0x3
> +#define FDT_END  0x9
> +
> + xMEMSIZE.reqx0
> + xMEMBASE.reqx1
> +
> + xLR .reqx8
> + xDTP.reqx9
> + xSTRTAB .reqx10
> + xMEMNODE.reqx11
> +
> + .text
> + .align  3
> +_memory:
> + .asciz  "memory"
> +_reg:
> + .asciz  "reg"
> +_device_type:
> + .asci

Re: [Xen-devel] [PATCH v1 09/21] ArmVirtualizationPkg: implement custom MemoryInitPeiLib

[Laszlo Ersek]

some notes

On 01/23/15 16:02, Ard Biesheuvel wrote:
> This implements a MemoryInitPeiLib instance that differs from the
> stock ArmPlatformPkg version only in the fact that it does not remove
> the memory used by the flash device (FD). The reason is that, when using
> PrePi, the DXE core is started immediately and never returns so there is
> no reason to preserve any of the memory that the flash device occupied
> originally, and it is preferable to release is so that the OS loader
> can reuse it. This is especially important for the relocatable PrePi
> configuration, which is aimed at being launched from a boot loader that
> itself adheres to the Linux arm64 boot protocol.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
>  .../ArmVirtualizationMemoryInitPeiLib.c| 91 
> ++
>  .../ArmVirtualizationMemoryInitPeiLib.inf  | 64 +++
>  2 files changed, 155 insertions(+)
>  create mode 100644 
> ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationMemoryInitPeiLib/ArmVirtualizationMemoryInitPeiLib.c
>  create mode 100644 
> ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationMemoryInitPeiLib/ArmVirtualizationMemoryInitPeiLib.inf
> 
> diff --git 
> a/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationMemoryInitPeiLib/ArmVirtualizationMemoryInitPeiLib.c
>  
> b/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationMemoryInitPeiLib/ArmVirtualizationMemoryInitPeiLib.c
> new file mode 100644
> index ..5f6cd059c47f
> --- /dev/null
> +++ 
> b/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationMemoryInitPeiLib/ArmVirtualizationMemoryInitPeiLib.c
> @@ -0,0 +1,91 @@
> +/** @file
> +*
> +*  Copyright (c) 2011-2014, ARM Limited. All rights reserved.
> +*  Copyright (c) 2014, Linaro Limited. All rights reserved.
> +*
> +*  This program and the accompanying materials
> +*  are licensed and made available under the terms and conditions of the BSD 
> License
> +*  which accompanies this distribution.  The full text of the license may be 
> found at
> +*  http://opensource.org/licenses/bsd-license.php
> +*
> +*  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +*  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
> IMPLIED.
> +*
> +**/
> +
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +VOID
> +BuildMemoryTypeInformationHob (
> +  VOID
> +  );
> +
> +VOID
> +InitMmu (
> +  VOID
> +  )
> +{
> +  ARM_MEMORY_REGION_DESCRIPTOR  *MemoryTable;
> +  VOID  *TranslationTableBase;
> +  UINTN TranslationTableSize;
> +  RETURN_STATUS Status;
> +
> +  // Get Virtual Memory Map from the Platform Library
> +  ArmPlatformGetVirtualMemoryMap (&MemoryTable);
> +
> +  //Note: Because we called PeiServicesInstallPeiMemory() before to call 
> InitMmu() the MMU Page Table resides in
> +  //  DRAM (even at the top of DRAM as it is the first permanent memory 
> allocation)
> +  Status = ArmConfigureMmu (MemoryTable, &TranslationTableBase, 
> &TranslationTableSize);
> +  if (EFI_ERROR (Status)) {
> +DEBUG ((EFI_D_ERROR, "Error: Failed to enable MMU\n"));
> +  }
> +}
> +
> +EFI_STATUS
> +EFIAPI
> +MemoryPeim (
> +  IN EFI_PHYSICAL_ADDRESS   UefiMemoryBase,
> +  IN UINT64 UefiMemorySize
> +  )
> +{
> +  EFI_RESOURCE_ATTRIBUTE_TYPE ResourceAttributes;
> +
> +  // Ensure PcdSystemMemorySize has been set
> +  ASSERT (PcdGet64 (PcdSystemMemorySize) != 0);
> +
> +  //
> +  // Now, the permanent memory has been installed, we can call 
> AllocatePages()
> +  //
> +  ResourceAttributes = (
> +  EFI_RESOURCE_ATTRIBUTE_PRESENT |
> +  EFI_RESOURCE_ATTRIBUTE_INITIALIZED |
> +  EFI_RESOURCE_ATTRIBUTE_UNCACHEABLE |
> +  EFI_RESOURCE_ATTRIBUTE_WRITE_COMBINEABLE |
> +  EFI_RESOURCE_ATTRIBUTE_WRITE_THROUGH_CACHEABLE |
> +  EFI_RESOURCE_ATTRIBUTE_WRITE_BACK_CACHEABLE |
> +  EFI_RESOURCE_ATTRIBUTE_TESTED
> +  );
> +
> +  BuildResourceDescriptorHob (
> +  EFI_RESOURCE_SYSTEM_MEMORY,
> +  ResourceAttributes,
> +  PcdGet64 (PcdSystemMemoryBase),
> +  PcdGet64 (PcdSystemMemorySize)
> +  );
> +
> +  // Build Memory Allocation Hob
> +  InitMmu ();
> +
> +  if (FeaturePcdGet (PcdPrePiProduceMemoryTypeInformationHob)) {
> +// Optional feature that helps prevent EFI memory map fragmentation.
> +BuildMemoryTypeInformationHob ();
> +  }
> +
> +  return EFI_SUCCESS;
> +}
> diff --git 
> a/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationMemoryInitPeiLib/ArmVirtualizationMemoryInitPeiLib.inf
>  
> b/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationMemoryInitPeiLib/ArmVirtualizationMemoryInitPeiLib.inf
> new file mode 100644
> index ..1031f64fb8de
> --- /dev/null
> +++ 
> b/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationMemoryInitPeiLib/Ar

Re: [Xen-devel] [PATCH v1 05/21] ArmVirtualizationPkg: use a HOB to store device tree blob

[Laszlo Ersek]

I reviewed the discussion under

http://lists.linaro.org/pipermail/linaro-uefi/2014-December/000601.html

and I can see that you addressed all points there. I have some new comments:

On 01/23/15 16:02, Ard Biesheuvel wrote:
> Instead of using a dynamic PCD, store the device tree address in a HOB
> so that we can also run under a configuration that does not support
> dynamic PCDs.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
>  .../ArmVirtualizationPkg/ArmVirtualizationPkg.dec  |  3 +--
>  .../ArmVirtualizationPkg/ArmVirtualizationQemu.dsc |  3 ---
>  .../ArmVirtualizationPkg/Include/Guid/FdtHob.h | 26 
> ++
>  .../ArmVirtualizationPlatformLib.inf   |  1 +
>  .../Library/PlatformPeiLib/PlatformPeiLib.c| 12 ++
>  .../Library/PlatformPeiLib/PlatformPeiLib.inf  |  3 ---
>  .../ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c   | 10 +++--
>  .../ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.inf |  3 ++-
>  8 files changed, 46 insertions(+), 15 deletions(-)
>  create mode 100644 ArmPlatformPkg/ArmVirtualizationPkg/Include/Guid/FdtHob.h
> 
> diff --git a/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationPkg.dec 
> b/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationPkg.dec
> index 99411548aff6..cc7d31d62d6c 100644
> --- a/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationPkg.dec
> +++ b/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationPkg.dec
> @@ -33,6 +33,7 @@
>  [Guids.common]
>gArmVirtualizationTokenSpaceGuid = { 0x0B6F5CA7, 0x4F53, 0x445A, { 0xB7, 
> 0x6E, 0x2E, 0x36, 0x5B, 0x80, 0x63, 0x66 } }
>gEarlyPL011BaseAddressGuid   = { 0xB199DEA9, 0xFD5C, 0x4A84, { 0x80, 
> 0x82, 0x2F, 0x41, 0x70, 0x78, 0x03, 0x05 } }
> +  gFdtHobGuid  = { 0x16958446, 0x19B7, 0x480B, { 0xB0, 
> 0x47, 0x74, 0x85, 0xAD, 0x3F, 0x71, 0x6D } }
>  
>  [PcdsFixedAtBuild]
>#
> @@ -44,8 +45,6 @@
>
> gArmVirtualizationTokenSpaceGuid.PcdDeviceTreeInitialBaseAddress|0x0|UINT64|0x0001
>  
>  [PcdsDynamic, PcdsFixedAtBuild]
> -  
> gArmVirtualizationTokenSpaceGuid.PcdDeviceTreeBaseAddress|0x0|UINT64|0x0002
> -
>#
># ARM PSCI function invocations can be done either through hypervisor
># calls (HVC) or secure monitor calls (SMC).
> diff --git a/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationQemu.dsc 
> b/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationQemu.dsc
> index dff4e2507058..4f8eb632143c 100644
> --- a/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationQemu.dsc
> +++ b/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationQemu.dsc
> @@ -160,9 +160,6 @@
># System Memory Size -- 1 MB initially, actual size will be fetched from DT
>gArmTokenSpaceGuid.PcdSystemMemorySize|0x0010
>  
> -  # location of the device tree blob passed by QEMU
> -  gArmVirtualizationTokenSpaceGuid.PcdDeviceTreeBaseAddress|0x0
> -
>gArmTokenSpaceGuid.PcdArmArchTimerSecIntrNum|0x0
>gArmTokenSpaceGuid.PcdArmArchTimerIntrNum|0x0
>gArmTokenSpaceGuid.PcdArmArchTimerVirtIntrNum|0x0
> diff --git a/ArmPlatformPkg/ArmVirtualizationPkg/Include/Guid/FdtHob.h 
> b/ArmPlatformPkg/ArmVirtualizationPkg/Include/Guid/FdtHob.h
> new file mode 100644
> index ..287729e0c350
> --- /dev/null
> +++ b/ArmPlatformPkg/ArmVirtualizationPkg/Include/Guid/FdtHob.h
> @@ -0,0 +1,26 @@
> +/** @file
> +  GUID for the HOB that contains the copy of the flattened device tree blob
> +
> +  Copyright (C) 2014, Linaro Ltd.
> +
> +  This program and the accompanying materials are licensed and made available
> +  under the terms and conditions of the BSD License that accompanies this
> +  distribution. The full text of the license may be found at
> +  http://opensource.org/licenses/bsd-license.php.
> +
> +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, 
> WITHOUT
> +  WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
> +
> +**/
> +
> +#ifndef __FDT_HOB_H__
> +#define __FDT_HOB_H__
> +
> +#define FDT_HOB_GUID { \
> +  0x16958446, 0x19B7, 0x480B, \
> +  { 0xB0, 0x47, 0x74, 0x85, 0xAD, 0x3F, 0x71, 0x6D } \
> +}
> +
> +extern EFI_GUID gFdtHobGuid;
> +
> +#endif
> diff --git 
> a/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/ArmVirtualizationPlatformLib.inf
>  
> b/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/ArmVirtualizationPlatformLib.inf
> index d1572882af1b..cb048232c0c0 100644
> --- 
> a/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/ArmVirtualizationPlatformLib.inf
> +++ 
> b/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/ArmVirtualizationPlatformLib.inf
> @@ -65,3 +65,4 @@
>  
>  [Guids]
>gEarlyPL011BaseAddressGuid
> +  gFdtHobGuid

I think that this change should not occur to this file (you're not using
the new GUID in this module), but to
"ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformPeiLib/Platform

[Xen-devel] [linux-arm-xen baseline test] 33685: tolerable FAIL

[xen . org]

"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate.  The baseline, if
any, is the most recent actually tested revision.

flight 33685 linux-arm-xen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33685/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt  9 guest-start  fail   never pass
 test-armhf-armhf-xl  10 migrate-support-checkfail   never pass

version targeted for testing:
 linux780a61e9af6d5634897feabd0f1cb3fecea41590
baseline version:
 linux95bfbee422b9b1cfe8c2d2e27edf17ce1cc99e04


4002 people touched revisions under test,
not listing them all


jobs:
 build-armhf  pass
 build-armhf-libvirt  pass
 build-armhf-pvopspass
 test-armhf-armhf-xl  pass
 test-armhf-armhf-libvirt fail



sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
http://www.chiark.greenend.org.uk/~xensrcts/logs

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


Push not applicable.

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

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

Re: [Xen-devel] [PATCH v1 04/21] ArmVirtualizationPkg: move early UART discovery to PlatformPeim

[Laszlo Ersek]

On 01/23/15 16:02, Ard Biesheuvel wrote:
> This is partially motivated by the desire to use PrePi in a virt
> environment, and in that configuration, ArmPlatformInitializeMemory()
> is never called. But actually, this is a more suitable place anyway.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Reviewed-by: Laszlo Ersek 
> Signed-off-by: Ard Biesheuvel 
> ---
>  .../Library/ArmVirtualizationPlatformLib/Virt.c| 46 +
>  .../Library/PlatformPeiLib/PlatformPeiLib.c| 48 
> ++
>  2 files changed, 50 insertions(+), 44 deletions(-)
> 
> diff --git 
> a/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/Virt.c
>  
> b/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/Virt.c
> index 3e3074af72f1..17f268697583 100644
> --- 
> a/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/Virt.c
> +++ 
> b/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/Virt.c
> @@ -24,9 +24,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
> -#include 
> -#include 
>  
>  /**
>Return the current Boot Mode
> @@ -77,25 +74,13 @@ ArmPlatformInitializeSystemMemory (
>INT32Node, Prev;
>UINT64   NewBase;
>UINT64   NewSize;
> -  BOOLEAN  HaveMemory, HaveUART;
> -  UINT64   *HobData;
>CONST CHAR8  *Type;
> -  CONST CHAR8  *Compatible;
> -  CONST CHAR8  *CompItem;
>INT32Len;
>CONST UINT64 *RegProp;
> -  UINT64   UartBase;
>  
>NewBase = 0;
>NewSize = 0;
>  
> -  HaveMemory = FALSE;
> -  HaveUART   = FALSE;
> -
> -  HobData = BuildGuidHob (&gEarlyPL011BaseAddressGuid, sizeof *HobData);
> -  ASSERT (HobData != NULL);
> -  *HobData = 0;
> -
>DeviceTreeBase = (VOID *)(UINTN)PcdGet64 (PcdDeviceTreeInitialBaseAddress);
>ASSERT (DeviceTreeBase != NULL);
>  
> @@ -107,7 +92,7 @@ ArmPlatformInitializeSystemMemory (
>//
>// Look for a memory node
>//
> -  for (Prev = 0; !(HaveMemory && HaveUART); Prev = Node) {
> +  for (Prev = 0;; Prev = Node) {
>  Node = fdt_next_node (DeviceTreeBase, Prev, NULL);
>  if (Node < 0) {
>break;
> @@ -140,34 +125,7 @@ ArmPlatformInitializeSystemMemory (
>  DEBUG ((EFI_D_ERROR, "%a: Failed to parse FDT memory node\n",
> __FUNCTION__));
>}
> -  HaveMemory = TRUE;
> -  continue;
> -}
> -
> -//
> -// Check for UART node
> -//
> -Compatible = fdt_getprop (DeviceTreeBase, Node, "compatible", &Len);
> -
> -//
> -// Iterate over the NULL-separated items in the compatible string
> -//
> -for (CompItem = Compatible; CompItem != NULL && CompItem < Compatible + 
> Len;
> -  CompItem += 1 + AsciiStrLen (CompItem)) {
> -
> -  if (AsciiStrCmp (CompItem, "arm,pl011") == 0) {
> -RegProp = fdt_getprop (DeviceTreeBase, Node, "reg", &Len);
> -ASSERT (Len == 16);
> -
> -UartBase = fdt64_to_cpu (ReadUnaligned64 (RegProp));
> -
> -DEBUG ((EFI_D_INFO, "%a: PL011 UART @ 0x%lx\n", __FUNCTION__, 
> UartBase));
> -
> -*HobData = UartBase;
> -
> -HaveUART = TRUE;
> -continue;
> -  }
> +  break;
>  }
>}
>  
> diff --git 
> a/ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformPeiLib/PlatformPeiLib.c 
> b/ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformPeiLib/PlatformPeiLib.c
> index af0d6e87da9f..58bc2b828dcd 100644
> --- 
> a/ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformPeiLib/PlatformPeiLib.c
> +++ 
> b/ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformPeiLib/PlatformPeiLib.c
> @@ -21,6 +21,8 @@
>  #include 
>  #include 
>  
> +#include 
> +
>  EFI_STATUS
>  EFIAPI
>  PlatformPeim (
> @@ -30,6 +32,14 @@ PlatformPeim (
>VOID   *Base;
>VOID   *NewBase;
>UINTN  FdtSize;
> +  UINT64 *UartHobData;
> +  INT32  Node, Prev;
> +  CONST CHAR8*Compatible;
> +  CONST CHAR8*CompItem;
> +  INT32  Len;
> +  CONST UINT64   *RegProp;
> +  UINT64 UartBase;
> +
>  
>Base = (VOID*)(UINTN)FixedPcdGet64 (PcdDeviceTreeInitialBaseAddress);
>ASSERT (fdt_check_header (Base) == 0);
> @@ -41,6 +51,44 @@ PlatformPeim (
>CopyMem (NewBase, Base, FdtSize);
>PcdSet64 (PcdDeviceTreeBaseAddress, (UINT64)(UINTN)NewBase);
>  
> +  UartHobData = BuildGuidHob (&gEarlyPL011BaseAddressGuid, sizeof 
> *UartHobData);
> +  ASSERT (UartHobData != NULL);
> +  *UartHobData = 0;
> +
> +  //
> +  // Look for a UART node
> +  //
> +  for (Prev = 0;; Prev = Node) {
> +Node = fdt_next_node (Base, Prev, NULL);
> +if (Node < 0) {
> +  break;
> +}
> +
> +//
> +// Check for UART node
> +//
> +Compatible = fdt_getprop (Base, Node, "compatible", &Len);
> +
> +//
> +// Iterate over the NULL-separated items in the compatible string
> +//
> +for (CompItem = Compatible; CompItem != NULL && CompItem < Compa

Re: [Xen-devel] [PATCH v1 03/21] ArmVirtualizationPkg: replace instance of FixedPcdGet()

[Laszlo Ersek]

On 01/23/15 16:02, Ard Biesheuvel wrote:
> This removes an instance of FixedPcdGet () so that the self relocating
> PrePi instance can poke another value into it.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
>  .../ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/Virt.c| 2 
> +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git 
> a/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/Virt.c
>  
> b/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/Virt.c
> index aa4ced4582e8..3e3074af72f1 100644
> --- 
> a/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/Virt.c
> +++ 
> b/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/Virt.c
> @@ -96,7 +96,7 @@ ArmPlatformInitializeSystemMemory (
>ASSERT (HobData != NULL);
>*HobData = 0;
>  
> -  DeviceTreeBase = (VOID *)(UINTN)FixedPcdGet64 
> (PcdDeviceTreeInitialBaseAddress);
> +  DeviceTreeBase = (VOID *)(UINTN)PcdGet64 (PcdDeviceTreeInitialBaseAddress);
>ASSERT (DeviceTreeBase != NULL);
>  
>//
> 

Care to include some more rationale in the commit message? From here:

http://lists.linaro.org/pipermail/linaro-uefi/2014-December/000604.html
http://lists.linaro.org/pipermail/linaro-uefi/2014-December/000613.html

You're gearing up to something nasty here, so it bears a bit more
explanation IMO :)

Also, after the relocation, FixedPcdGet64() and PcdGet64() would not
return the same value for the same PCD (despite it being a fixed PCD),
which is presumably a "first" in edk2. I can't recommend an alternative,
but please put a warning comment in the code.

Acked-by: Laszlo Ersek 

Thanks
Laszlo

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

[Xen-devel] [PATCH v2 SECURITY-POLICY 8/9] Clarify what announcements may be made by to service users

[Ian Jackson]

Service provider list members should not be prevented from being
reasonably honest with their users.

Signed-off-by: Ian Jackson 
Signed-off-by: Ian Jackson 
---
 security_vulnerability_process.html |8 
 1 file changed, 8 insertions(+)

diff --git a/security_vulnerability_process.html 
b/security_vulnerability_process.html
index 7412652..3b9c1ba 100644
--- a/security_vulnerability_process.html
+++ b/security_vulnerability_process.html
@@ -222,6 +222,14 @@ restrictions only insofar as it is necessary to prevent 
the exposure
 of technicalities (for example, differences in behaviour) which
 present a significant risk of rediscovery of the vulnerability.  Such
 situations are expected to be rare.
+Where the list member is a service provider who intends to take
+disruptive action such as rebooting as part of deploying a fix: the
+list member's communications to its users about the service disruption
+may mention that the disruption is to correct a security issue, and
+relate it to the public information about the issue (as listed above).
+This applies whether the deployment occurs during the embargo (with
+permission - see above) or is planned for after the end of the
+embargo.
 NOTE: Prior v2.2 of this policy (25 June 2014) it was
 permitted to also make available the allocated CVE number. This is no
 longer permitted in accordance with MITRE policy.
-- 
1.7.10.4


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

[Xen-devel] [PATCH v2 SECURITY-POLICY 1/9] Grammar fix: Remove a comma splice

[Ian Jackson]

No semantic change.

Signed-off-by: Ian Jackson 
Signed-off-by: Ian Jackson 
---
 security_vulnerability_process.html |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/security_vulnerability_process.html 
b/security_vulnerability_process.html
index 7069646..4ed0042 100644
--- a/security_vulnerability_process.html
+++ b/security_vulnerability_process.html
@@ -246,7 +246,7 @@ advisories. Please include in the e-mail:
 or have not sent a statement that they have read this policy and will
 abide by, it will be asked to do so. 
 Organisations should not request subscription via the mailing list
-web interface, any such subscription requests will be rejected and
+web interface.  Any such subscription requests will be rejected and
 ignored.
 A role address (such
 as mailto:secur...@example.com";>secur...@example.com)
-- 
1.7.10.4


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

[Xen-devel] [PATCH v2 SECURITY-POLICY 9/9] Document changes in changelog and heading

[Ian Jackson]

IMPLEMENTATION TASKS:
 * Assign last change date to be approval date
 * Reformat html to web page CMS format
 * Update web page

Signed-off-by: Ian Jackson 
Signed-off-by: Ian Jackson 
---
 security_vulnerability_process.html |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/security_vulnerability_process.html 
b/security_vulnerability_process.html
index 3b9c1ba..9ca7622 100644
--- a/security_vulnerability_process.html
+++ b/security_vulnerability_process.html
@@ -1,6 +1,6 @@
 This document has come in effect in December 2011 and will be
 reviewed periodically (see revision sections). The last modification
-has been made in October 2014.
+has been made in (approval date tbd).
 Introduction
 Computer systems have bugs. Currently recognised best practice for
 bugs with security implications is to notify significant downstream
@@ -385,6 +385,8 @@ email addresses or internal business groups).
 Change History
 
   
+v3.0 (approval date TBD): New predisclosure list 
application
+process and information-sharing and -handling rules; and, minor 
clarifications.
 v2.7 Oct 21st 2014: Added the following
 vendors to the pre-disclosure list: OnePoundWebHosting Ltd, File
 Sanctuary, iWeb Technologies Inc., Memset
-- 
1.7.10.4


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

[Xen-devel] [PATCH v2 SECURITY-POLICY 5/9] Tighten, and make more objective, predisclosure list application

[Ian Jackson]

Applicants should be required to:

  - Provide information on their public web pages which makes
it clear that and why they are eligible;

  - Specifically, publicly state that and how they are using Xen
(so that the Security Team can verify eligibility);

  - Provide a way for members of the public to responsibly report
security problems to the applicant, just as the Xen Project does.

The Security Team should be forbidden from trying to hunt down
eligibility information etc. and should instead be mandated to reject
incomplete requests.

Also remove the "case-by-case-basis" membership exception.  This is
not consistent with the new objective membership application process.

Signed-off-by: Ian Jackson 
Signed-off-by: Ian Jackson 
---
 security_vulnerability_process.html |   79 ---
 1 file changed, 54 insertions(+), 25 deletions(-)

diff --git a/security_vulnerability_process.html 
b/security_vulnerability_process.html
index 8870f8d..de8fd44 100644
--- a/security_vulnerability_process.html
+++ b/security_vulnerability_process.html
@@ -176,9 +176,7 @@ development, is very likely to be accepted; whereas a 
project with a
 single developer who spends a few hours a month will most likey be
 rejected.
 For organizational users, a rule of thumb is that "large scale"
-means an installed base of 300,000 or more Xen guests. Other
-well-established organisations with a mature security response process
-will be considered on a case-by-case basis.
+means an installed base of 300,000 or more Xen guests.
 The list of entities on the pre-disclosure list is public. (Just
 the list of projects and organisations, not the actual email
 addresses.)
@@ -231,35 +229,66 @@ longer permitted in accordance with MITRE policy.
 predisclosure-applications@xenprojectorg
 (which is a public mailing list) if they wish to receive
 pre-disclosure of advisories.
-Please include in the e-mail:
+You must include in the e-mail:
 
   The name of your organization
-  A brief description of why you fit the criteria, along with
-  evidence to support the claim
-  A security alias e-mail address (no personal addresses -- see
-  below)
-  A link to a web page with your security policy statement
+  Domain name(s) which you use to provide Xen software/services
+  A brief description of why you fit the criteria
+  If not all of your products/services use Xen, a list of (some
+  of) your products/services (or categories thereof) which do.
+  Link(s) to current public web pages, belonging to your
+  organisation, for each of following pieces of information:
+
+  Evidence of your status as a service/software provider:
+
+  If you are a public hosting provider, your public rates
+  or how to get a quote
+  If you are a software provider, how your
+  software can be downloaded or purchased
+  If you are an open-source project, a mailing list
+  archive and/or version control repository, with
+  active development
+
+  
+  Evidence of your status as a user/distributor of Xen:
+
+  Statements about, or descriptions of, your eligible
+  production services or released software, from which it is
+  immediately evident that they use Xen.
+
+  
+  Information about your handling of security problems:
+
+  Your invitation to members of the public, who discover
+  security problems with your products/services, to report
+  them in confidence to you;
+  Specifically, the contact information (email addresses or
+  other contact instructions) which such a member of the
+  public should use.
+
+  
+
+Blog postings, conference presentations, social media pages,
+Flash presentations, videos, sites which require registration,
+anything password-protected, etc., are not acceptable.  PDFs of
+reasonable size are acceptable so long as the URL you provide is
+of a ordinary HTML page providing a link to the PDF.
+If the pages are long and/or PDFs are involved, your email
+should say which part of the pages and documents are relevant.
+  
   A statement to the effect that you have read this policy and
   agree to abide by the terms for inclusion in the list, specifically
   the requirements to regarding confidentiality during an embargo
   period
-  Evidence that will be considered may include the following:
-
-  If you are a public hosting provider, a link to a web page
-  with your public rates
-  If you are a software provider, a link to a web page where
-  your software can be downloaded or purchased
-  If you are an open-source project, a link to a mailing list
-  archive and/or a version control repository demonstrating active
-  development
-  A public key signed with a key which is in the PGP "strong
-  set"
-
-  
+  The single (non-personal) email

[Xen-devel] [PATCH v2 SECURITY-POLICY 0/9] Security policy ambiguities - XSA-108 process post-mortem

[Ian Jackson]

I would like to propose the following series of changes to the Xen
Project Security Policy.  For readability I have presented them as
diffs to a reasonably-plausibly-formatted HTML.

The substance of each change is discussed in the corresponding commit
message.

I am going to wait a week to see if anyone has any further comments.
If not, I will ask the Xen Project Community Manager to conduct the
formal approval process.


You can find the git tree I am using here:
  http://xenbits.xen.org/gitweb/?p=people/iwj/security-process.git;a=shortlog;h\
=refs/heads/rebasing
The relevant changes are in master..rebasing.

I have put a copy of the bare HTML here:
  http://xenbits.xen.org/people/iwj/draft/security_vulnerability_process.html


This is v2 of the series of changes.  The only comments were minor and
technical, and have (I think) been addressed.  The changes in v2 of the
series compared to my previous patch-series proposal:
 * Add IMPLEMENTATION TASKS section to various of the commit messages
 * Minor wording changes (no semantic change compared to v1)
 * Better presentation of email addresses (no semantic change)

Thanks,
Ian.

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

[Xen-devel] [PATCH v2 SECURITY-POLICY 7/9] Clarify and fix prior consultation text

[Ian Jackson]

The prior consultation clause should applies to all disclosure
exceptions.  The list end appears to have been moved by mistake.  So
put it back.

Also, no longer suggest that predisclosure list members should consult
with the discoverer, since the discoverer is not generally known to
predisclosure list members.

Signed-off-by: Ian Jackson 
Signed-off-by: Ian Jackson 
---
 security_vulnerability_process.html |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/security_vulnerability_process.html 
b/security_vulnerability_process.html
index 2d32e51..7412652 100644
--- a/security_vulnerability_process.html
+++ b/security_vulnerability_process.html
@@ -200,9 +200,10 @@ partners:
   the impact, scope, set of vulnerable systems or the nature of
   the vulnerability
   revision control commits which are a fix for the problem
-  patched software (even in binary form) without prior
-  consultation with security@xenproject and/or the discoverer.
+  patched software (even in binary form)
 
+without prior
+consultation with security@xenproject.
 List members are allowed to make available to their users only the
 following:
 
-- 
1.7.10.4


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

[Xen-devel] [PATCH v2 SECURITY-POLICY 2/9] Add headings

[Ian Jackson]

 - For Predisclosure list application process
 - For Handling of embargoed information"

No semantic change.

Signed-off-by: Ian Jackson 
Signed-off-by: Ian Jackson 
---
 security_vulnerability_process.html |2 ++
 1 file changed, 2 insertions(+)

diff --git a/security_vulnerability_process.html 
b/security_vulnerability_process.html
index 4ed0042..010cf76 100644
--- a/security_vulnerability_process.html
+++ b/security_vulnerability_process.html
@@ -186,6 +186,7 @@ addresses.)
 of the advisory and patches, with a clearly marked embargo date, as
 soon as they are available. The pre-disclosure list will also receive
 copies of public advisories when they are first issued or updated
+Handling of embargoed information
 Organizations on the pre-disclosure list are expected to maintain
 the confidentiality of the vulnerability up to the embargo date which
 security@xenproject have agreed with the discoverer, and are
@@ -214,6 +215,7 @@ following:
 NOTE: Prior v2.2 of this policy (25 June 2014) it was
 permitted to also make available the allocated CVE number. This is no
 longer permitted in accordance with MITRE policy.
+Predisclosure list membership application process
 Organisations who meet the criteria should contact
 security@xenproject if they wish to receive pre-disclosure of
 advisories. Please include in the e-mail:
-- 
1.7.10.4


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

[Xen-devel] [PATCH v2 SECURITY-POLICY 4/9] Use a public mailing list for predisclosure membership applications.

[Ian Jackson]

IMPLEMENTATION TASKS:
 * Create the mailing list (and check that it works from outside)

Signed-off-by: Ian Jackson 
Signed-off-by: Ian Jackson 

---
v2: Provide whole email address for predisclosure-applications@,
but obfuscate it with  and a .
Reword sentence about public mailing list as suggested by
Ian Campbell.
---
 security_vulnerability_process.html |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/security_vulnerability_process.html 
b/security_vulnerability_process.html
index de5e83e..8870f8d 100644
--- a/security_vulnerability_process.html
+++ b/security_vulnerability_process.html
@@ -228,8 +228,10 @@ permitted to also make available the allocated CVE number. 
This is no
 longer permitted in accordance with MITRE policy.
 Predisclosure list membership application process
 Organisations who meet the criteria should contact
-security@xenproject if they wish to receive pre-disclosure of
-advisories. Please include in the e-mail:
+predisclosure-applications@xenprojectorg
+(which is a public mailing list) if they wish to receive
+pre-disclosure of advisories.
+Please include in the e-mail:
 
   The name of your organization
   A brief description of why you fit the criteria, along with
-- 
1.7.10.4


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

[Xen-devel] [PATCH v2 SECURITY-POLICY 3/9] Deployment with Security Team Permission

[Ian Jackson]

Permitting deployment during embargo seemed to have rough consensus on
the principle.  We seemed to be converging on the idea that the
Security Team should explicitly set deployment restrictions for each
set of patches.

IMPLEMENTATION TASKS:
 * Add new section to Security Team's advisory template.
 * Add new section to any existing outstanding embargoed advisories.

Signed-off-by: Ian Jackson 
Signed-off-by: Ian Jackson 
---
 security_vulnerability_process.html |   11 +++
 1 file changed, 11 insertions(+)

diff --git a/security_vulnerability_process.html 
b/security_vulnerability_process.html
index 010cf76..de5e83e 100644
--- a/security_vulnerability_process.html
+++ b/security_vulnerability_process.html
@@ -212,6 +212,17 @@ following:
   The assigned XSA number
   The planned disclosure date
 
+List members may, if (and only if) the Security Team grants
+permission, deploy fixed versions during the embargo.  Permission for
+deployment, and any restrictions, will be stated in the embargoed
+advisory text.
+The Security Team will normally permit such deployment, even for
+systems where VMs are managed or used by non-members of the
+predisclosure list.  The Security Team will impose deployment
+restrictions only insofar as it is necessary to prevent the exposure
+of technicalities (for example, differences in behaviour) which
+present a significant risk of rediscovery of the vulnerability.  Such
+situations are expected to be rare.
 NOTE: Prior v2.2 of this policy (25 June 2014) it was
 permitted to also make available the allocated CVE number. This is no
 longer permitted in accordance with MITRE policy.
-- 
1.7.10.4


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

[Xen-devel] [PATCH v2 SECURITY-POLICY 6/9] Explicitly permit within-list information sharing during embargo

[Ian Jackson]

Permitting sharing of embargoed fixes amongst predisclosure list
seemed to have appropriate consensus.

IMPLEMENTATION TASKS:
 * Send a notification to the existing predisclosure list members
   informing them that they have been subscribed to the new list.
   Notice should point them to the policy section on filtering
   by List-Id, and offer to unsubscribe them from both lists if
   they prefer.
 * Create the new mailing list, and
   - check that it can be emailed from outside
   - that messages are held for moderation and can be approved

Signed-off-by: Ian Jackson 
Signed-off-by: Ian Jackson 

---
v2: Obfuscate -discuss@ list's full email address with 
and .
---
 security_vulnerability_process.html |   21 +
 1 file changed, 21 insertions(+)

diff --git a/security_vulnerability_process.html 
b/security_vulnerability_process.html
index de8fd44..2d32e51 100644
--- a/security_vulnerability_process.html
+++ b/security_vulnerability_process.html
@@ -224,6 +224,27 @@ situations are expected to be rare.
 NOTE: Prior v2.2 of this policy (25 June 2014) it was
 permitted to also make available the allocated CVE number. This is no
 longer permitted in accordance with MITRE policy.
+Information-sharing amongst predisclosure list members
+Predisclosure list members are allowed to share fixes to embargoed issues,
+analysis, etc., with the security teams of other list members.
+Technical measures must be taken to prevents non-list-member
+organisations, or unauthorised staff in list-member organisations,
+from obtaining the embargoed materials.
+The Xen Project provides the mailing list
+xen-security-issues-discuss@lists.xenprojectorg
+for this purpose.  List members are encouraged to use it but
+may share with other list members' security teams via other
+channels.
+The -discuss list's distribution is identical to that of the 
primary
+predisclosure list xen-security-issues.  Recipient organisations 
who
+do not wish to receive all of the traffic on -discuss should use
+recipient-side email filtering based on the provided List-Id.
+The -discuss list is moderated by the Xen Project Security 
Team.
+Announcements of private availability of fixed versions, and
+technical messages about embargoed advisories, will be approved.
+Messages dealing with policy matters will be rejected with a
+reference to the Security Team contact address and/or public Xen
+mailing lists.
 Predisclosure list membership application process
 Organisations who meet the criteria should contact
 predisclosure-applications@xenprojectorg
-- 
1.7.10.4


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

Re: [Xen-devel] [PATCH v1 20/21] ArmVirtualizationPkg/VirtFdtDxe: wire up XenBusDxe to "xen, xen" DT node

[Ard Biesheuvel]

On 23 January 2015 at 19:03, Stefano Stabellini
 wrote:
> On Fri, 23 Jan 2015, Ard Biesheuvel wrote:
>> This patchs adds support to VirtFdtDxe for the Xen DT node which
>> contains the base address of the Grant Table. This data is communicated
>> to XenBusDxe using a XENIO_PROTOCOL instance.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Ard Biesheuvel 
>> ---
>>  .../ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c   | 96 
>> +++---
>>  .../ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.inf |  2 +
>>  2 files changed, 86 insertions(+), 12 deletions(-)
>>
>> diff --git a/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c 
>> b/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c
>> index 96aeec61ee7f..d8071f3e72aa 100644
>> --- a/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c
>> +++ b/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c
>> @@ -30,6 +30,9 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>> +
>> +#include 
>>
>>  #pragma pack (1)
>>  typedef struct {
>> @@ -39,6 +42,13 @@ typedef struct {
>>  } VIRTIO_TRANSPORT_DEVICE_PATH;
>>  #pragma pack ()
>>
>> +#pragma pack (1)
>> +typedef struct {
>> +  VENDOR_DEVICE_PATH  Vendor;
>> +  EFI_DEVICE_PATH_PROTOCOLEnd;
>> +} XENBUS_ROOT_DEVICE_PATH;
>> +#pragma pack ()
>> +
>>  typedef enum {
>>PropertyTypeUnknown,
>>PropertyTypeGic,
>> @@ -49,6 +59,7 @@ typedef enum {
>>PropertyTypePsci,
>>PropertyTypeFwCfg,
>>PropertyTypeGicV3,
>> +  PropertyTypeXen,
>>  } PROPERTY_TYPE;
>>
>>  typedef struct {
>> @@ -66,6 +77,7 @@ STATIC CONST PROPERTY CompatibleProperties[] = {
>>{ PropertyTypePsci,"arm,psci-0.2"},
>>{ PropertyTypeFwCfg,   "qemu,fw-cfg-mmio"},
>>{ PropertyTypeGicV3,   "arm,gic-v3"  },
>> +  { PropertyTypeXen, "xen,xen" },
>>{ PropertyTypeUnknown, ""}
>>  };
>>
>> @@ -116,7 +128,7 @@ InitializeVirtFdtDxe (
>>INT32  Len;
>>PROPERTY_TYPE  PropType;
>>CONST VOID *RegProp;
>> -  VIRTIO_TRANSPORT_DEVICE_PATH   *DevicePath;
>> +  VIRTIO_TRANSPORT_DEVICE_PATH   *VirtIoDevicePath;
>
> Why are you renaming this variable as part of this patch? It makes
> reading this patch harder than necessary.

Not strictly necessary, I suppose. There is a second device path
pointer now with a different type, and I wanted to distinguish between
them.

> If it is required, I would do it in a separate patch. At the very least
> it should be mentioned in the commit message.
>

OK

>
>>EFI_HANDLE Handle;
>>UINT64 RegBase;
>>UINT64 DistBase, CpuBase;
>> @@ -127,6 +139,8 @@ InitializeVirtFdtDxe (
>>UINT64 FwCfgSelectorSize;
>>UINT64 FwCfgDataAddress;
>>UINT64 FwCfgDataSize;
>> +  XENIO_PROTOCOL *XenIo;
>> +  XENBUS_ROOT_DEVICE_PATH*XenBusDevicePath;
>>
>>Hob = GetFirstGuidHob(&gFdtHobGuid);
>>if (Hob == NULL || GET_GUID_HOB_DATA_SIZE (Hob) != sizeof DeviceTreeBase) 
>> {
>> @@ -209,31 +223,31 @@ InitializeVirtFdtDxe (
>>// Create a unique device path for this transport on the fly
>>//
>>RegBase = fdt64_to_cpu (((UINT64 *)RegProp)[0]);
>> -  DevicePath = (VIRTIO_TRANSPORT_DEVICE_PATH *)CreateDeviceNode (
>> +  VirtIoDevicePath = (VIRTIO_TRANSPORT_DEVICE_PATH *)CreateDeviceNode (
>>  HARDWARE_DEVICE_PATH,
>>  HW_VENDOR_DP,
>>  sizeof (VIRTIO_TRANSPORT_DEVICE_PATH));
>> -  if (DevicePath == NULL) {
>> +  if (VirtIoDevicePath == NULL) {
>>  DEBUG ((EFI_D_ERROR, "%a: Out of memory\n", __FUNCTION__));
>>  break;
>>}
>>
>> -  CopyMem (&DevicePath->Vendor.Guid, &gVirtioMmioTransportGuid,
>> +  CopyMem (&VirtIoDevicePath->Vendor.Guid, &gVirtioMmioTransportGuid,
>>  sizeof (EFI_GUID));
>> -  DevicePath->PhysBase = RegBase;
>> -  SetDevicePathNodeLength (&DevicePath->Vendor,
>> -   sizeof (*DevicePath) - sizeof 
>> (DevicePath->End));
>> -  SetDevicePathEndNode (&DevicePath->End);
>> +  VirtIoDevicePath->PhysBase = RegBase;
>> +  SetDevicePathNodeLength (&VirtIoDevicePath->Vendor,
>> +   sizeof (*VirtIoDevicePath) - sizeof 
>> (VirtIoDevicePath->End));
>> +  SetDevicePathEndNode (&VirtIoDevicePath->End);
>>
>>Handle = NULL;
>>Status = gBS->InstallProtocolInterface (&Handle,
>>   &gEfiDevicePathProtocolGuid, EFI_NATIVE_INTERFACE,
>> - DevicePath);
>> + VirtIoDevicePath);
>>if (EFI_ERROR (Status)) {
>>  DEBUG ((EFI_D_ERROR, "%a: Failed to install the EFI_DEVICE_PATH "
>>  

Re: [Xen-devel] [PATCH v1 02/21] ArmVirtualizationPkg: add GICv3 detection to VirtFdtDxe

[Laszlo Ersek]

On 01/23/15 16:02, Ard Biesheuvel wrote:
> This adds support for detecting the presence of a GICv3 interrupt
> controller from the device tree, and recording its distributor
> base address in a PCD.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
>  .../ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c  | 19 
> +++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c 
> b/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c
> index 4e4f608923d3..8953f78f5fe4 100644
> --- a/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c
> +++ b/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c
> @@ -46,6 +46,7 @@ typedef enum {
>PropertyTypeTimer,
>PropertyTypePsci,
>PropertyTypeFwCfg,
> +  PropertyTypeGicV3,
>  } PROPERTY_TYPE;
>  
>  typedef struct {
> @@ -62,6 +63,7 @@ STATIC CONST PROPERTY CompatibleProperties[] = {
>{ PropertyTypeTimer,   "arm,armv8-timer" },
>{ PropertyTypePsci,"arm,psci-0.2"},
>{ PropertyTypeFwCfg,   "qemu,fw-cfg-mmio"},
> +  { PropertyTypeGicV3,   "arm,gic-v3"  },
>{ PropertyTypeUnknown, ""}
>  };
>  
> @@ -256,6 +258,23 @@ InitializeVirtFdtDxe (
>DEBUG ((EFI_D_INFO, "Found GIC @ 0x%Lx/0x%Lx\n", DistBase, CpuBase));
>break;
>  
> +case PropertyTypeGicV3:
> +  //
> +  // The GIC v3 DT binding describes a series of at least 3 physical base
> +  // addresses, but we are only interested in the first one, which is the
> +  // distributor interface. (We use the system register CPU interface, 
> not
> +  // the MMIO one)
> +  //
> +  ASSERT (Len >= 16);
> +
> +  DistBase = fdt64_to_cpu (((UINT64 *)RegProp)[0]);
> +  ASSERT (DistBase < MAX_UINT32);
> +
> +  PcdSet32 (PcdGicDistributorBase, (UINT32)DistBase);
> +
> +  DEBUG ((EFI_D_INFO, "Found GIC v3 distributor @ 0x%Lx\n", DistBase));
> +  break;
> +
>  case PropertyTypeRtc:
>ASSERT (Len == 16);
>  
> 

Acked-by: Laszlo Ersek 

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

Re: [Xen-devel] [PATCH v1 17/21] Ovmf/Xen: add Xen PV console SerialPortLib driver

[Ard Biesheuvel]

On 23 January 2015 at 18:54, Stefano Stabellini
 wrote:
> On Fri, 23 Jan 2015, Ard Biesheuvel wrote:
>> This implements a SerialPortLib instance that wires up to the
>> PV console ring used by domU guests. Also imports the required
>> upstream Xen io/console.h header.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Ard Biesheuvel 
>> ---
>>  OvmfPkg/Include/IndustryStandard/Xen/io/console.h  |  51 +++
>>  .../XenConsoleSerialPortLib.c  | 147 
>> +
>>  .../XenConsoleSerialPortLib.inf|  34 +
>>  3 files changed, 232 insertions(+)
>>  create mode 100644 OvmfPkg/Include/IndustryStandard/Xen/io/console.h
>>  create mode 100644 
>> OvmfPkg/Library/XenConsoleSerialPortLib/XenConsoleSerialPortLib.c
>>  create mode 100644 
>> OvmfPkg/Library/XenConsoleSerialPortLib/XenConsoleSerialPortLib.inf
>>
>> diff --git a/OvmfPkg/Include/IndustryStandard/Xen/io/console.h 
>> b/OvmfPkg/Include/IndustryStandard/Xen/io/console.h
>> new file mode 100644
>> index ..f1caa9765bcf
>> --- /dev/null
>> +++ b/OvmfPkg/Include/IndustryStandard/Xen/io/console.h
>> @@ -0,0 +1,51 @@
>> +/**
>> + * console.h
>> + *
>> + * Console I/O interface for Xen guest OSes.
>> + *
>> + * Permission is hereby granted, free of charge, to any person obtaining a 
>> copy
>> + * of this software and associated documentation files (the "Software"), to
>> + * deal in the Software without restriction, including without limitation 
>> the
>> + * rights to use, copy, modify, merge, publish, distribute, sublicense, 
>> and/or
>> + * sell copies of the Software, and to permit persons to whom the Software 
>> is
>> + * furnished to do so, subject to the following conditions:
>> + *
>> + * The above copyright notice and this permission notice shall be included 
>> in
>> + * all copies or substantial portions of the Software.
>> + *
>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS 
>> OR
>> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
>> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL 
>> THE
>> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
>> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
>> + * DEALINGS IN THE SOFTWARE.
>> + *
>> + * Copyright (c) 2005, Keir Fraser
>> + */
>> +
>> +#ifndef __XEN_PUBLIC_IO_CONSOLE_H__
>> +#define __XEN_PUBLIC_IO_CONSOLE_H__
>> +
>> +typedef UINT32 XENCONS_RING_IDX;
>> +
>> +#define MASK_XENCONS_IDX(idx, ring) ((idx) & (sizeof(ring)-1))
>> +
>> +struct xencons_interface {
>> +char in[1024];
>> +char out[2048];
>> +XENCONS_RING_IDX in_cons, in_prod;
>> +XENCONS_RING_IDX out_cons, out_prod;
>> +};
>> +
>> +#endif /* __XEN_PUBLIC_IO_CONSOLE_H__ */
>> +
>> +/*
>> + * Local variables:
>> + * mode: C
>> + * c-file-style: "BSD"
>> + * c-basic-offset: 4
>> + * tab-width: 4
>> + * indent-tabs-mode: nil
>> + * End:
>> + */
>> diff --git 
>> a/OvmfPkg/Library/XenConsoleSerialPortLib/XenConsoleSerialPortLib.c 
>> b/OvmfPkg/Library/XenConsoleSerialPortLib/XenConsoleSerialPortLib.c
>> new file mode 100644
>> index ..97344dc4efb0
>> --- /dev/null
>> +++ b/OvmfPkg/Library/XenConsoleSerialPortLib/XenConsoleSerialPortLib.c
>> @@ -0,0 +1,147 @@
>> +/** @file
>> +  Xen console SerialPortLib instance
>> +
>> +  Copyright (c) 2015, Linaro Ltd. All rights reserved.
>> +
>> +  This program and the accompanying materials
>> +  are licensed and made available under the terms and conditions of the BSD 
>> License
>> +  which accompanies this distribution.  The full text of the license may be 
>> found at
>> +  http://opensource.org/licenses/bsd-license.php
>> +
>> +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
>> +  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
>> IMPLIED.
>> +
>> +**/
>> +
>> +#include 
>> +#include 
>> +
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include 
>> +#include 
>> +#include 
>> +
>> +STATIC evtchn_send_t  mXenConsoleEventChain;
>> +STATIC struct xencons_interface   *mXenConsoleInterface;
>> +
>> +RETURN_STATUS
>> +EFIAPI
>> +SerialPortInitialize (
>> +  VOID
>> +  )
>> +{
>> +  mXenConsoleEventChain.port = (UINT32)XenHypercallHvmGetParam 
>> (HVM_PARAM_CONSOLE_EVTCHN);
>> +  mXenConsoleInterface = (struct xencons_interface *)(UINTN)
>> +(XenHypercallHvmGetParam (HVM_PARAM_CONSOLE_PFN) << EFI_PAGE_SHIFT);
>> +
>> +  //
>> +  // No point in ASSERT'ing here as we won't be seeing the output
>> +  //
>> +  return RETURN_SUCCESS;
>> +}
>> +
>> +/**
>> +  Write data to serial device.
>> +
>> +  @param  Buffer   Point of data buffer which need to be written.
>> +  @param  NumberOfBytesNumber of output bytes which are cached in

Re: [Xen-devel] [PATCH v1 01/21] ArmPkg: allow HYP timer interrupt to be omitted

[Laszlo Ersek]

On 01/23/15 16:02, Ard Biesheuvel wrote:
> The DT binding for the ARM generic timer describes the secure,
> non-secure, virtual and hypervisor timer interrupts, respectively.
> However, under virtualization, only the virtual timer is usable, and
> the device tree may omit the hypervisor timer interrupt. (Other timer
> interrupts cannot be omitted simply due to the fact that the virtual
> timer is listed third)
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
>  ArmPkg/Drivers/TimerDxe/TimerDxe.c | 14 
> +++---
>  .../ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c   |  4 ++--
>  2 files changed, 13 insertions(+), 5 deletions(-)
> 
> diff --git a/ArmPkg/Drivers/TimerDxe/TimerDxe.c 
> b/ArmPkg/Drivers/TimerDxe/TimerDxe.c
> index d0a819fc2729..1169d426b255 100644
> --- a/ArmPkg/Drivers/TimerDxe/TimerDxe.c
> +++ b/ArmPkg/Drivers/TimerDxe/TimerDxe.c
> @@ -369,7 +369,8 @@ TimerInitialize (
>  {
>EFI_HANDLE  Handle = NULL;
>EFI_STATUS  Status;
> -  UINTN TimerCtrlReg;
> +  UINTN   TimerCtrlReg;
> +  UINT32  TimerHypIntrNum;
>  
>if (ArmIsArchTimerImplemented () == 0) {
>  DEBUG ((EFI_D_ERROR, "ARM Architectural Timer is not available in the 
> CPU, hence cann't use this Driver \n"));
> @@ -395,8 +396,15 @@ TimerInitialize (
>Status = gInterrupt->RegisterInterruptSource (gInterrupt, PcdGet32 
> (PcdArmArchTimerVirtIntrNum), TimerInterruptHandler);
>ASSERT_EFI_ERROR (Status);
>  
> -  Status = gInterrupt->RegisterInterruptSource (gInterrupt, PcdGet32 
> (PcdArmArchTimerHypIntrNum), TimerInterruptHandler);
> -  ASSERT_EFI_ERROR (Status);
> +  //
> +  // The hypervisor timer interrupt may be omitted by implementations that
> +  // execute under virtualization.
> +  //
> +  TimerHypIntrNum = PcdGet32 (PcdArmArchTimerHypIntrNum);
> +  if (TimerHypIntrNum != 0) {
> +Status = gInterrupt->RegisterInterruptSource (gInterrupt, 
> TimerHypIntrNum, TimerInterruptHandler);
> +ASSERT_EFI_ERROR (Status);
> +  }
>  
>Status = gInterrupt->RegisterInterruptSource (gInterrupt, PcdGet32 
> (PcdArmArchTimerSecIntrNum), TimerInterruptHandler);
>ASSERT_EFI_ERROR (Status);
> diff --git a/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c 
> b/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c
> index 751864d4db9c..4e4f608923d3 100644
> --- a/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c
> +++ b/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c
> @@ -274,7 +274,7 @@ InitializeVirtFdtDxe (
>//  hypervisor timers, in that order.
>//
>InterruptProp = fdt_getprop (DeviceTreeBase, Node, "interrupts", &Len);
> -  ASSERT (Len == 48);
> +  ASSERT (Len == 36 || Len == 48);
>  
>SecIntrNum = fdt32_to_cpu (InterruptProp[0].Number)
> + (InterruptProp[0].Type ? 16 : 0);
> @@ -282,7 +282,7 @@ InitializeVirtFdtDxe (
>  + (InterruptProp[1].Type ? 16 : 0);
>VirtIntrNum = fdt32_to_cpu (InterruptProp[2].Number)
>  + (InterruptProp[2].Type ? 16 : 0);
> -  HypIntrNum = fdt32_to_cpu (InterruptProp[3].Number)
> +  HypIntrNum = Len < 48 ? 0 : fdt32_to_cpu (InterruptProp[3].Number)
> + (InterruptProp[3].Type ? 16 : 0);
>  
>DEBUG ((EFI_D_INFO, "Found Timer interrupts %d, %d, %d, %d\n",
> 

Please align the plus sign on the second line with the first addend. The
layout should reflect operator binding if possible.

Thanks
Laszlo

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

Re: [Xen-devel] [RFC v4 2/2] x86/xen: allow privcmd hypercalls to be preempted

[Luis R. Rodriguez]

On Fri, Jan 23, 2015 at 11:45:06AM +, David Vrabel wrote:
> > + */
> > +void xen_end_upcall(struct pt_regs *regs)
> > +{
> > +   if (xen_is_preemptible_hypercall(regs)) {
> > +   int cpuid = smp_processor_id();
> > +   if (_cond_resched())
> > +   trace_xen_hypercall_preemption(cpuid);
> 
> I don't think a tracepoint here is useful.

OK.. I'll remove.

> > +   }
> > +}
> > +NOKPROBE_SYMBOL(xen_end_upcall);
> 
> Do we need this is this function is no longer notrace?

Stephen and Andy were going down some corner case rabbit hole
and it seemed to me that the conclusion was not settled so
to be safe I kept it. I'll let them decide. I did remove
the notrace junk.

  Luis

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

Re: [Xen-devel] [PATCH v1 00/21] Xen/ARM guest support

[Laszlo Ersek]

On 01/23/15 16:02, Ard Biesheuvel wrote:

>  ArmPkg/Drivers/TimerDxe/TimerDxe.c |  14 +-
>  .../ArmVirtualizationPkg/ArmVirtualizationPkg.dec  |   3 +-
>  .../ArmVirtualizationPkg/ArmVirtualizationQemu.dsc |   3 -
>  .../ArmVirtualizationPkg/ArmVirtualizationXen.dsc  | 274 +
>  .../ArmVirtualizationPkg/ArmVirtualizationXen.fdf  | 337 
>  .../ArmVirtualizationPkg/Include/Guid/FdtHob.h |  26 ++
>  .../ArmVirtualizationMemoryInitPeiLib.c|  91 +
>  .../ArmVirtualizationMemoryInitPeiLib.inf  |  64 +++
>  .../AARCH64/MemnodeParser.S| 232 +++
>  .../AARCH64/RelocatableVirtHelper.S| 161 
>  .../ArmVirtualizationPlatformLib.inf   |   1 +
>  .../ArmXenRelocatablePlatformLib.inf   |  66 
>  .../ArmVirtualizationPlatformLib/RelocatableVirt.c |  78 
>  .../Library/ArmVirtualizationPlatformLib/Virt.c|  48 +--
>  .../ArmVirtualizationPlatformLib/XenVirtMem.c  |  83 
>  .../Library/PlatformPeiLib/PlatformPeiLib.c|  75 +++-
>  .../Library/PlatformPeiLib/PlatformPeiLib.inf  |   3 -
>  .../ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c   | 129 +-
>  .../ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.inf |   5 +-
>  ArmPlatformPkg/PrePi/AArch64/ModuleEntryPoint.S|  51 ++-
>  ArmPlatformPkg/PrePi/MainMPCore.c  |   5 +-
>  ArmPlatformPkg/PrePi/MainUniCore.c |   2 +-
>  ArmPlatformPkg/PrePi/MainUniCoreRelocatable.c  |  38 ++
>  ArmPlatformPkg/PrePi/PeiUniCoreRelocatable.inf | 108 +
>  ArmPlatformPkg/PrePi/PrePi.c   |  25 +-
>  ArmPlatformPkg/PrePi/PrePi.h   |   3 +-
>  ArmPlatformPkg/PrePi/Scripts/PrePi-PIE.lds |  28 ++
>  OvmfPkg/Include/Guid/XenBusRootDevice.h|  24 ++
>  .../Include/IndustryStandard/Xen/arch-arm/xen.h| 436 
> +
>  OvmfPkg/Include/IndustryStandard/Xen/io/console.h  |  51 +++
>  OvmfPkg/Include/IndustryStandard/Xen/xen.h |   7 +-
>  OvmfPkg/Include/Library/XenHypercallLib.h  |  78 
>  OvmfPkg/Include/Protocol/XenIo.h   |  48 +++
>  .../XenConsoleSerialPortLib.c  | 147 +++
>  .../XenConsoleSerialPortLib.inf|  34 ++
>  .../Library/XenHypercallLib/Aarch64/Hypercall.S|  26 ++
>  OvmfPkg/Library/XenHypercallLib/Arm/Hypercall.S|  25 ++
>  .../XenHypercallLib}/Ia32/hypercall.nasm   |   6 +-
>  .../XenHypercallLib}/X64/hypercall.nasm|   6 +-
>  .../Library/XenHypercallLib/XenHypercallLibArm.inf |  40 ++
>  .../XenHypercallLib/XenHypercallLibCommon.c|  63 +++
>  .../Library/XenHypercallLib/XenHypercallLibIntel.c |  77 
>  .../XenHypercallLib/XenHypercallLibIntel.inf   |  52 +++
>  .../XenRealTimeClockLib/XenRealTimeClockLib.c  | 196 +
>  .../XenRealTimeClockLib/XenRealTimeClockLib.inf|  38 ++
>  OvmfPkg/OvmfPkg.dec|   6 +
>  OvmfPkg/OvmfPkgIa32.dsc|   1 +
>  OvmfPkg/OvmfPkgIa32X64.dsc |   1 +
>  OvmfPkg/OvmfPkgX64.dsc |   1 +
>  OvmfPkg/XenBusDxe/AtomicsGcc.c |  44 +++
>  OvmfPkg/XenBusDxe/ComponentName.c  |   2 +-
>  OvmfPkg/XenBusDxe/EventChannel.c   |  14 +-
>  OvmfPkg/XenBusDxe/GrantTable.c |  15 +-
>  OvmfPkg/XenBusDxe/GrantTable.h |   3 +-
>  OvmfPkg/XenBusDxe/XenBus.c |   6 +-
>  OvmfPkg/XenBusDxe/XenBusDxe.c  | 241 ++--
>  OvmfPkg/XenBusDxe/XenBusDxe.h  |   8 +-
>  OvmfPkg/XenBusDxe/XenBusDxe.inf|  15 +-
>  OvmfPkg/XenBusDxe/XenHypercall.c   | 118 --
>  OvmfPkg/XenBusDxe/XenHypercall.h   | 113 --
>  OvmfPkg/XenBusDxe/XenStore.c   |   6 +-
>  OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.h  |   4 -

Just a very quick skim for now, because you'll probably submit a v2 with
the more fine-grained structure requested by Stefano (which I welcome,
because it'll be easier to review).

First: please don't forget --stat=150 next time :)

Thanks
Laszlo

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

Re: [Xen-devel] [PATCH v1 20/21] ArmVirtualizationPkg/VirtFdtDxe: wire up XenBusDxe to "xen, xen" DT node

[Stefano Stabellini]

On Fri, 23 Jan 2015, Ard Biesheuvel wrote:
> This patchs adds support to VirtFdtDxe for the Xen DT node which
> contains the base address of the Grant Table. This data is communicated
> to XenBusDxe using a XENIO_PROTOCOL instance.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
>  .../ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c   | 96 
> +++---
>  .../ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.inf |  2 +
>  2 files changed, 86 insertions(+), 12 deletions(-)
> 
> diff --git a/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c 
> b/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c
> index 96aeec61ee7f..d8071f3e72aa 100644
> --- a/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c
> +++ b/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c
> @@ -30,6 +30,9 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +
> +#include 
>  
>  #pragma pack (1)
>  typedef struct {
> @@ -39,6 +42,13 @@ typedef struct {
>  } VIRTIO_TRANSPORT_DEVICE_PATH;
>  #pragma pack ()
>  
> +#pragma pack (1)
> +typedef struct {
> +  VENDOR_DEVICE_PATH  Vendor;
> +  EFI_DEVICE_PATH_PROTOCOLEnd;
> +} XENBUS_ROOT_DEVICE_PATH;
> +#pragma pack ()
> +
>  typedef enum {
>PropertyTypeUnknown,
>PropertyTypeGic,
> @@ -49,6 +59,7 @@ typedef enum {
>PropertyTypePsci,
>PropertyTypeFwCfg,
>PropertyTypeGicV3,
> +  PropertyTypeXen,
>  } PROPERTY_TYPE;
>  
>  typedef struct {
> @@ -66,6 +77,7 @@ STATIC CONST PROPERTY CompatibleProperties[] = {
>{ PropertyTypePsci,"arm,psci-0.2"},
>{ PropertyTypeFwCfg,   "qemu,fw-cfg-mmio"},
>{ PropertyTypeGicV3,   "arm,gic-v3"  },
> +  { PropertyTypeXen, "xen,xen" },
>{ PropertyTypeUnknown, ""}
>  };
>  
> @@ -116,7 +128,7 @@ InitializeVirtFdtDxe (
>INT32  Len;
>PROPERTY_TYPE  PropType;
>CONST VOID *RegProp;
> -  VIRTIO_TRANSPORT_DEVICE_PATH   *DevicePath;
> +  VIRTIO_TRANSPORT_DEVICE_PATH   *VirtIoDevicePath;

Why are you renaming this variable as part of this patch? It makes
reading this patch harder than necessary.
If it is required, I would do it in a separate patch. At the very least
it should be mentioned in the commit message.


>EFI_HANDLE Handle;
>UINT64 RegBase;
>UINT64 DistBase, CpuBase;
> @@ -127,6 +139,8 @@ InitializeVirtFdtDxe (
>UINT64 FwCfgSelectorSize;
>UINT64 FwCfgDataAddress;
>UINT64 FwCfgDataSize;
> +  XENIO_PROTOCOL *XenIo;
> +  XENBUS_ROOT_DEVICE_PATH*XenBusDevicePath;
>  
>Hob = GetFirstGuidHob(&gFdtHobGuid);
>if (Hob == NULL || GET_GUID_HOB_DATA_SIZE (Hob) != sizeof DeviceTreeBase) {
> @@ -209,31 +223,31 @@ InitializeVirtFdtDxe (
>// Create a unique device path for this transport on the fly
>//
>RegBase = fdt64_to_cpu (((UINT64 *)RegProp)[0]);
> -  DevicePath = (VIRTIO_TRANSPORT_DEVICE_PATH *)CreateDeviceNode (
> +  VirtIoDevicePath = (VIRTIO_TRANSPORT_DEVICE_PATH *)CreateDeviceNode (
>  HARDWARE_DEVICE_PATH,
>  HW_VENDOR_DP,
>  sizeof (VIRTIO_TRANSPORT_DEVICE_PATH));
> -  if (DevicePath == NULL) {
> +  if (VirtIoDevicePath == NULL) {
>  DEBUG ((EFI_D_ERROR, "%a: Out of memory\n", __FUNCTION__));
>  break;
>}
>  
> -  CopyMem (&DevicePath->Vendor.Guid, &gVirtioMmioTransportGuid,
> +  CopyMem (&VirtIoDevicePath->Vendor.Guid, &gVirtioMmioTransportGuid,
>  sizeof (EFI_GUID));
> -  DevicePath->PhysBase = RegBase;
> -  SetDevicePathNodeLength (&DevicePath->Vendor,
> -   sizeof (*DevicePath) - sizeof 
> (DevicePath->End));
> -  SetDevicePathEndNode (&DevicePath->End);
> +  VirtIoDevicePath->PhysBase = RegBase;
> +  SetDevicePathNodeLength (&VirtIoDevicePath->Vendor,
> +   sizeof (*VirtIoDevicePath) - sizeof 
> (VirtIoDevicePath->End));
> +  SetDevicePathEndNode (&VirtIoDevicePath->End);
>  
>Handle = NULL;
>Status = gBS->InstallProtocolInterface (&Handle,
>   &gEfiDevicePathProtocolGuid, EFI_NATIVE_INTERFACE,
> - DevicePath);
> + VirtIoDevicePath);
>if (EFI_ERROR (Status)) {
>  DEBUG ((EFI_D_ERROR, "%a: Failed to install the EFI_DEVICE_PATH "
>"protocol on a new handle (Status == %r)\n",
>__FUNCTION__, Status));
> -FreePool (DevicePath);
> +FreePool (VirtIoDevicePath);
>  break;
>}
>  
> @@ -244,9 +258,9 @@ InitializeVirtFdtDxe (
>Handle, Status));
>  
>  Status = gBS->UninstallProto

Re: [Xen-devel] [PATCH v1 15/21] Ovmf/Xen: implement XenHypercallLib for ARM

[Ard Biesheuvel]

On 23 January 2015 at 18:41, Stefano Stabellini
 wrote:
> On Fri, 23 Jan 2015, Ard Biesheuvel wrote:
>> This patch adds an implementation of XenHypercallLib for both
>> AArch64 and AArch32 execution modes on ARM systems.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Ard Biesheuvel 
>> ---
>>  .../Include/IndustryStandard/Xen/arch-arm/xen.h| 436 
>> +
>>  OvmfPkg/Include/IndustryStandard/Xen/xen.h |   2 +-
>>  .../Library/XenHypercallLib/Aarch64/Hypercall.S|  26 ++
>>  OvmfPkg/Library/XenHypercallLib/Arm/Hypercall.S|  25 ++
>>  .../Library/XenHypercallLib/XenHypercallLibArm.inf |  40 ++
>>  5 files changed, 528 insertions(+), 1 deletion(-)
>>  create mode 100644 OvmfPkg/Include/IndustryStandard/Xen/arch-arm/xen.h
>>  create mode 100644 OvmfPkg/Library/XenHypercallLib/Aarch64/Hypercall.S
>>  create mode 100644 OvmfPkg/Library/XenHypercallLib/Arm/Hypercall.S
>>  create mode 100644 OvmfPkg/Library/XenHypercallLib/XenHypercallLibArm.inf
>>
>> diff --git a/OvmfPkg/Include/IndustryStandard/Xen/arch-arm/xen.h 
>> b/OvmfPkg/Include/IndustryStandard/Xen/arch-arm/xen.h
>> new file mode 100644
>> index ..655a221f6337
>> --- /dev/null
>> +++ b/OvmfPkg/Include/IndustryStandard/Xen/arch-arm/xen.h
>> @@ -0,0 +1,436 @@
>> +/**
>> + * arch-arm.h
>> + *
>> + * Guest OS interface to ARM Xen.
>> + *
>> + * Permission is hereby granted, free of charge, to any person obtaining a 
>> copy
>> + * of this software and associated documentation files (the "Software"), to
>> + * deal in the Software without restriction, including without limitation 
>> the
>> + * rights to use, copy, modify, merge, publish, distribute, sublicense, 
>> and/or
>> + * sell copies of the Software, and to permit persons to whom the Software 
>> is
>> + * furnished to do so, subject to the following conditions:
>> + *
>> + * The above copyright notice and this permission notice shall be included 
>> in
>> + * all copies or substantial portions of the Software.
>> + *
>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS 
>> OR
>> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
>> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL 
>> THE
>> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
>> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
>> + * DEALINGS IN THE SOFTWARE.
>> + *
>> + * Copyright 2011 (C) Citrix Systems
>> + */
>> +
>> +#ifndef __XEN_PUBLIC_ARCH_ARM_H__
>> +#define __XEN_PUBLIC_ARCH_ARM_H__
>> +
>> +/*
>> + * `incontents 50 arm_abi Hypercall Calling Convention
>> + *
>> + * A hypercall is issued using the ARM HVC instruction.
>> + *
>> + * A hypercall can take up to 5 arguments. These are passed in
>> + * registers, the first argument in x0/r0 (for arm64/arm32 guests
>> + * respectively irrespective of whether the underlying hypervisor is
>> + * 32- or 64-bit), the second argument in x1/r1, the third in x2/r2,
>> + * the forth in x3/r3 and the fifth in x4/r4.
>> + *
>> + * The hypercall number is passed in r12 (arm) or x16 (arm64). In both
>> + * cases the relevant ARM procedure calling convention specifies this
>> + * is an inter-procedure-call scratch register (e.g. for use in linker
>> + * stubs). This use does not conflict with use during a hypercall.
>> + *
>> + * The HVC ISS must contain a Xen specific TAG: XEN_HYPERCALL_TAG.
>> + *
>> + * The return value is in x0/r0.
>> + *
>> + * The hypercall will clobber x16/r12 and the argument registers used
>> + * by that hypercall (except r0 which is the return value) i.e. in
>> + * addition to x16/r12 a 2 argument hypercall will clobber x1/r1 and a
>> + * 4 argument hypercall will clobber x1/r1, x2/r2 and x3/r3.
>> + *
>> + * Parameter structs passed to hypercalls are laid out according to
>> + * the Procedure Call Standard for the ARM Architecture (AAPCS, AKA
>> + * EABI) and Procedure Call Standard for the ARM 64-bit Architecture
>> + * (AAPCS64). Where there is a conflict the 64-bit standard should be
>> + * used regardless of guest type. Structures which are passed as
>> + * hypercall arguments are always little endian.
>> + *
>> + * All memory which is shared with other entities in the system
>> + * (including the hypervisor and other guests) must reside in memory
>> + * which is mapped as Normal Inner-cacheable. This applies to:
>> + *  - hypercall arguments passed via a pointer to guest memory.
>> + *  - memory shared via the grant table mechanism (including PV I/O
>> + *rings etc).
>> + *  - memory shared with the hypervisor (struct shared_info, struct
>> + *vcpu_info, the grant table, etc).
>> + *
>> + * Any Inner cache allocation strategy (Write-Back, Write-Through etc)
>> + * is acceptable. There is no restricti

Re: [Xen-devel] [RFC v4 0/2] x86/xen: add xen hypercall preemption

[Luis R. Rodriguez]

On Fri, Jan 23, 2015 at 11:51:09AM +, David Vrabel wrote:
> On 23/01/15 00:29, Luis R. Rodriguez wrote:
> > From: "Luis R. Rodriguez" 
> > 
> > This v4 addresses some of the cleanups recommended and adds
> > tracing option for when we do actually preempt a hypercall.
> > I kept the NOKPROBE_SYMBOL() for now but did remove the 'notrace'
> > stuff.
> > 
> > This goes out as RFC still as I have not been able to test 32-bit.
> > Can anyone test that or at least confirm that the 32-bit point
> > we do the upcall is definitely not on the IRQ stack?
> 
> You can omit fixing this for 32-bit guests (provided you note as such in
> the commit message).

I'll be happy to do that.

 Luis

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

Re: [Xen-devel] [RFC v4 2/2] x86/xen: allow privcmd hypercalls to be preempted

[Luis R. Rodriguez]

On Fri, Jan 23, 2015 at 11:45:06AM +, David Vrabel wrote:
> On 23/01/15 00:29, Luis R. Rodriguez wrote:
> > From: "Luis R. Rodriguez" 
> > 
> > Xen has support for splitting heavy work work into a series
> > of hypercalls, called multicalls, and preempting them through
> > what Xen calls continuation [0]. Despite this though without
> > CONFIG_PREEMPT preemption won't happen, without preemption
> > a system can become pretty useless on heavy handed hypercalls.
> > Such is the case for example when creating a > 50 GiB HVM guest,
> > we can get softlockups [1] with:.
> > 
> > kernel: [  802.084335] BUG: soft lockup - CPU#1 stuck for 22s! [xend:31351]
> > 
> > The softlock up triggers on the TASK_UNINTERRUPTIBLE hanger check
> > (default 120 seconds), on the Xen side in this particular case
> > this happens when the following Xen hypervisor code is used:
> > 
> > xc_domain_set_pod_target() -->
> >   do_memory_op() -->
> > arch_memory_op() -->
> >   p2m_pod_set_mem_target()
> > -- long delay (real or emulated) --
> > 
> > This happens on arch_memory_op() on the XENMEM_set_pod_target memory
> > op even though arch_memory_op() can handle continuation via
> > hypercall_create_continuation() for example.
> > 
> > Machines over 50 GiB of memory are on high demand and hard to come
> > by so to help replicate this sort of issue long delays on select
> > hypercalls have been emulated in order to be able to test this on
> > smaller machines [2].
> > 
> > On one hand this issue can be considered as expected given that
> > CONFIG_PREEMPT=n is used however we have forced voluntary preemption
> > precedent practices in the kernel even for CONFIG_PREEMPT=n through
> > the usage of cond_resched() sprinkled in many places. To address
> > this issue with Xen hypercalls though we need to find a way to aid
> > to the schedular in the middle of hypercalls. We are motivated to
> > address this issue on CONFIG_PREEMPT=n as otherwise the system becomes
> > rather unresponsive for long periods of time; in the worst case, at least
> > only currently by emulating long delays on select io disk bound
> > hypercalls, this can lead to filesystem corruption if the delay happens
> > for example on SCHEDOP_remote_shutdown (when we call 'xl  
> > shutdown').
> > 
> > We can address this problem by trying to check if we should schedule
> > on the xen timer in the middle of a hypercall on the return from the
> > timer interrupt. We want to be careful to not always force voluntary
> > preemption though so to do this we only selectively enable preemption
> > on very specific xen hypercalls.
> [...]
> > @@ -1243,6 +1247,25 @@ void xen_evtchn_do_upcall(struct pt_regs *regs)
> > set_irq_regs(old_regs);
> >  }
> >  
> > +/*
> > + * CONFIG_PREEMPT=n kernels can end up triggering the softlock
> > + * TASK_UNINTERRUPTIBLE hanger check (default 120 seconds)
> > + * when certain multicalls are used [0] on large systems, in
> > + * that case we need a way to voluntarily preempt. This is
> > + * only an issue on CONFIG_PREEMPT=n kernels.
> 
> Rewrite this comment as;
> 
> * Some hypercalls issued by the toolstack can take many 10s of

Its not just hypercalls though, this is all about the interactions
with multicalls no?

> * seconds.  Allow tasks running hypercalls via the privcmd driver to be
> * voluntarily preempted even if full kernel preemption is disabled.
> 
> > + * [0] https://bugzilla.novell.com/show_bug.cgi?id=861093
> 
> This link isn't accessible so I don't think it should be included here.

OK.

 Luis

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

Re: [Xen-devel] [RFC v4 1/2] x86/xen: add xen_is_preemptible_hypercall()

[Luis R. Rodriguez]

On Fri, Jan 23, 2015 at 11:30:16AM +, David Vrabel wrote:
> On 23/01/15 00:29, Luis R. Rodriguez wrote:
> > From: "Luis R. Rodriguez" 
> > 
> > On kernels with voluntary or no preemption we can run
> > into situations where a hypercall issued through userspace
> > will linger around as it addresses sub-operatiosn in kernel
> > context (multicalls). Such operations can trigger soft lockup
> > detection.
> > 
> > We want to address a way to let the kernel voluntarily preempt
> > such calls even on non preempt kernels, to address this we first
> > need to distinguish which hypercalls fall under this category.
> > This implements xen_is_preemptible_hypercall() which lets us do
> > just that by adding a secondary hypercall page, calls made via
> > the new page may be preempted.
> [...]
> > --- a/arch/x86/include/asm/xen/hypercall.h
> > +++ b/arch/x86/include/asm/xen/hypercall.h
> > @@ -84,6 +84,22 @@
> >  
> >  extern struct { char _entry[32]; } hypercall_page[];
> >  
> > +#ifndef CONFIG_PREEMPT
> > +extern struct { char _entry[32]; } preemptible_hypercall_page[];
> > +
> > +static inline bool xen_is_preemptible_hypercall(struct pt_regs *regs)
> > +{
> > +   return !user_mode_vm(regs) &&
> > +   regs->ip >= (unsigned long)preemptible_hypercall_page &&
> > +   regs->ip < (unsigned long)preemptible_hypercall_page + 
> > PAGE_SIZE;
> 
> I think you can optimize this to:
> 
> return (regs->ip >> PAGE_SHIFT) == preemptible_hypercall_pfn

I take it you meant preemptible_hypercall_page ?

>   && !user_mode_vm(regs);

If so I don't see how this can work as an identical replacement.
Consider a PAGE_SIZE is 16, so PAGE_SHIFT would be 4, and lets
say we are checking for byte 2 which should be in the page:

; 0b0010 >>4
0

Can you elaborate more on this, or can we perhaps leave such
optimization as an evolution to avoid regressions if you are
not 100% certain?

  Luis

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

Re: [Xen-devel] [PATCH v1 17/21] Ovmf/Xen: add Xen PV console SerialPortLib driver

[Stefano Stabellini]

On Fri, 23 Jan 2015, Ard Biesheuvel wrote:
> This implements a SerialPortLib instance that wires up to the
> PV console ring used by domU guests. Also imports the required
> upstream Xen io/console.h header.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
>  OvmfPkg/Include/IndustryStandard/Xen/io/console.h  |  51 +++
>  .../XenConsoleSerialPortLib.c  | 147 
> +
>  .../XenConsoleSerialPortLib.inf|  34 +
>  3 files changed, 232 insertions(+)
>  create mode 100644 OvmfPkg/Include/IndustryStandard/Xen/io/console.h
>  create mode 100644 
> OvmfPkg/Library/XenConsoleSerialPortLib/XenConsoleSerialPortLib.c
>  create mode 100644 
> OvmfPkg/Library/XenConsoleSerialPortLib/XenConsoleSerialPortLib.inf
> 
> diff --git a/OvmfPkg/Include/IndustryStandard/Xen/io/console.h 
> b/OvmfPkg/Include/IndustryStandard/Xen/io/console.h
> new file mode 100644
> index ..f1caa9765bcf
> --- /dev/null
> +++ b/OvmfPkg/Include/IndustryStandard/Xen/io/console.h
> @@ -0,0 +1,51 @@
> +/**
> + * console.h
> + *
> + * Console I/O interface for Xen guest OSes.
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a 
> copy
> + * of this software and associated documentation files (the "Software"), to
> + * deal in the Software without restriction, including without limitation the
> + * rights to use, copy, modify, merge, publish, distribute, sublicense, 
> and/or
> + * sell copies of the Software, and to permit persons to whom the Software is
> + * furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL 
> THE
> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> + * DEALINGS IN THE SOFTWARE.
> + *
> + * Copyright (c) 2005, Keir Fraser
> + */
> +
> +#ifndef __XEN_PUBLIC_IO_CONSOLE_H__
> +#define __XEN_PUBLIC_IO_CONSOLE_H__
> +
> +typedef UINT32 XENCONS_RING_IDX;
> +
> +#define MASK_XENCONS_IDX(idx, ring) ((idx) & (sizeof(ring)-1))
> +
> +struct xencons_interface {
> +char in[1024];
> +char out[2048];
> +XENCONS_RING_IDX in_cons, in_prod;
> +XENCONS_RING_IDX out_cons, out_prod;
> +};
> +
> +#endif /* __XEN_PUBLIC_IO_CONSOLE_H__ */
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: "BSD"
> + * c-basic-offset: 4
> + * tab-width: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git 
> a/OvmfPkg/Library/XenConsoleSerialPortLib/XenConsoleSerialPortLib.c 
> b/OvmfPkg/Library/XenConsoleSerialPortLib/XenConsoleSerialPortLib.c
> new file mode 100644
> index ..97344dc4efb0
> --- /dev/null
> +++ b/OvmfPkg/Library/XenConsoleSerialPortLib/XenConsoleSerialPortLib.c
> @@ -0,0 +1,147 @@
> +/** @file
> +  Xen console SerialPortLib instance
> +
> +  Copyright (c) 2015, Linaro Ltd. All rights reserved.
> +
> +  This program and the accompanying materials
> +  are licensed and made available under the terms and conditions of the BSD 
> License
> +  which accompanies this distribution.  The full text of the license may be 
> found at
> +  http://opensource.org/licenses/bsd-license.php
> +
> +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
> IMPLIED.
> +
> +**/
> +
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +
> +STATIC evtchn_send_t  mXenConsoleEventChain;
> +STATIC struct xencons_interface   *mXenConsoleInterface;
> +
> +RETURN_STATUS
> +EFIAPI
> +SerialPortInitialize (
> +  VOID
> +  )
> +{
> +  mXenConsoleEventChain.port = (UINT32)XenHypercallHvmGetParam 
> (HVM_PARAM_CONSOLE_EVTCHN);
> +  mXenConsoleInterface = (struct xencons_interface *)(UINTN)
> +(XenHypercallHvmGetParam (HVM_PARAM_CONSOLE_PFN) << EFI_PAGE_SHIFT);
> +
> +  //
> +  // No point in ASSERT'ing here as we won't be seeing the output
> +  //
> +  return RETURN_SUCCESS;
> +}
> +
> +/**
> +  Write data to serial device.
> +
> +  @param  Buffer   Point of data buffer which need to be written.
> +  @param  NumberOfBytesNumber of output bytes which are cached in Buffer.
> +
> +  @retval 0Write data failed.
> +  @retval !0   Actual number of bytes written to serial device.
> +
> +**/
> +UINTN
> +EFIAPI
> +SerialPortWrite (
> +  IN UINT8 *Bu

Re: [Xen-devel] [PATCH v1 15/21] Ovmf/Xen: implement XenHypercallLib for ARM

[Stefano Stabellini]

On Fri, 23 Jan 2015, Ard Biesheuvel wrote:
> This patch adds an implementation of XenHypercallLib for both
> AArch64 and AArch32 execution modes on ARM systems.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
>  .../Include/IndustryStandard/Xen/arch-arm/xen.h| 436 
> +
>  OvmfPkg/Include/IndustryStandard/Xen/xen.h |   2 +-
>  .../Library/XenHypercallLib/Aarch64/Hypercall.S|  26 ++
>  OvmfPkg/Library/XenHypercallLib/Arm/Hypercall.S|  25 ++
>  .../Library/XenHypercallLib/XenHypercallLibArm.inf |  40 ++
>  5 files changed, 528 insertions(+), 1 deletion(-)
>  create mode 100644 OvmfPkg/Include/IndustryStandard/Xen/arch-arm/xen.h
>  create mode 100644 OvmfPkg/Library/XenHypercallLib/Aarch64/Hypercall.S
>  create mode 100644 OvmfPkg/Library/XenHypercallLib/Arm/Hypercall.S
>  create mode 100644 OvmfPkg/Library/XenHypercallLib/XenHypercallLibArm.inf
> 
> diff --git a/OvmfPkg/Include/IndustryStandard/Xen/arch-arm/xen.h 
> b/OvmfPkg/Include/IndustryStandard/Xen/arch-arm/xen.h
> new file mode 100644
> index ..655a221f6337
> --- /dev/null
> +++ b/OvmfPkg/Include/IndustryStandard/Xen/arch-arm/xen.h
> @@ -0,0 +1,436 @@
> +/**
> + * arch-arm.h
> + *
> + * Guest OS interface to ARM Xen.
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a 
> copy
> + * of this software and associated documentation files (the "Software"), to
> + * deal in the Software without restriction, including without limitation the
> + * rights to use, copy, modify, merge, publish, distribute, sublicense, 
> and/or
> + * sell copies of the Software, and to permit persons to whom the Software is
> + * furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL 
> THE
> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> + * DEALINGS IN THE SOFTWARE.
> + *
> + * Copyright 2011 (C) Citrix Systems
> + */
> +
> +#ifndef __XEN_PUBLIC_ARCH_ARM_H__
> +#define __XEN_PUBLIC_ARCH_ARM_H__
> +
> +/*
> + * `incontents 50 arm_abi Hypercall Calling Convention
> + *
> + * A hypercall is issued using the ARM HVC instruction.
> + *
> + * A hypercall can take up to 5 arguments. These are passed in
> + * registers, the first argument in x0/r0 (for arm64/arm32 guests
> + * respectively irrespective of whether the underlying hypervisor is
> + * 32- or 64-bit), the second argument in x1/r1, the third in x2/r2,
> + * the forth in x3/r3 and the fifth in x4/r4.
> + *
> + * The hypercall number is passed in r12 (arm) or x16 (arm64). In both
> + * cases the relevant ARM procedure calling convention specifies this
> + * is an inter-procedure-call scratch register (e.g. for use in linker
> + * stubs). This use does not conflict with use during a hypercall.
> + *
> + * The HVC ISS must contain a Xen specific TAG: XEN_HYPERCALL_TAG.
> + *
> + * The return value is in x0/r0.
> + *
> + * The hypercall will clobber x16/r12 and the argument registers used
> + * by that hypercall (except r0 which is the return value) i.e. in
> + * addition to x16/r12 a 2 argument hypercall will clobber x1/r1 and a
> + * 4 argument hypercall will clobber x1/r1, x2/r2 and x3/r3.
> + *
> + * Parameter structs passed to hypercalls are laid out according to
> + * the Procedure Call Standard for the ARM Architecture (AAPCS, AKA
> + * EABI) and Procedure Call Standard for the ARM 64-bit Architecture
> + * (AAPCS64). Where there is a conflict the 64-bit standard should be
> + * used regardless of guest type. Structures which are passed as
> + * hypercall arguments are always little endian.
> + *
> + * All memory which is shared with other entities in the system
> + * (including the hypervisor and other guests) must reside in memory
> + * which is mapped as Normal Inner-cacheable. This applies to:
> + *  - hypercall arguments passed via a pointer to guest memory.
> + *  - memory shared via the grant table mechanism (including PV I/O
> + *rings etc).
> + *  - memory shared with the hypervisor (struct shared_info, struct
> + *vcpu_info, the grant table, etc).
> + *
> + * Any Inner cache allocation strategy (Write-Back, Write-Through etc)
> + * is acceptable. There is no restriction on the Outer-cacheability.
> + */
> +
> +/*
> + * `incontents 55 arm_hcall Supported Hypercalls
> + *
> + * Xen on ARM makes extensive use of hardware facilities and the

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

[xen . org]

flight 33657 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33657/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-libvirt   5 libvirt-build fail REGR. vs. 33422

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt   9 guest-start  fail   never pass
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  9 guest-start  fail   never pass

version targeted for testing:
 libvirt  280ece4af95727eac49baaa48eb1a2fc36fad4ff
baseline version:
 libvirt  ce745914b33e3f9a136d91655600b931e7a4178f


People who touched revisions under test:
  Anthony PERARD 
  Cédric Bosdonnat 
  Daniel P. Berrange 
  Dmitry Guryanov 
  Erik Skultety 
  Gary R Hook 
  Gary R Hook 
  Jim Fehlig 
  Jiri Denemark 
  John Ferlan 
  Josh Stone 
  Ján Tomko 
  Kiarie Kahurani 
  Luyao Huang 
  Martin Kletzander 
  Michal Privoznik 
  Shivaprasad G Bhat 
  Shivaprasad G Bhat 


jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  fail
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt fail
 test-armhf-armhf-libvirt blocked
 test-amd64-i386-libvirt  fail



sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
http://www.chiark.greenend.org.uk/~xensrcts/logs

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


Not pushing.

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

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

[Xen-devel] [linux-linus test] 33664: tolerable FAIL - PUSHED

[xen . org]

flight 33664 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33664/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-freebsd10-i386  7 freebsd-install  fail like 33611
 test-amd64-i386-freebsd10-amd64  7 freebsd-install fail like 33611
 test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 33611
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install  fail like 33611

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start  fail  never pass
 test-armhf-armhf-libvirt  9 guest-start  fail   never pass
 test-amd64-i386-libvirt   9 guest-start  fail   never pass
 test-amd64-amd64-libvirt  9 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-amd   9 guest-start  fail   never pass
 test-armhf-armhf-xl  10 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stopfail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop  fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop   fail  never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop   fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop   fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop   fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass

version targeted for testing:
 linuxb942c653ae265abbd31032f3b4f5f857e5c7c723
baseline version:
 linuxb97f880c8342fd6e49a02c9ef7507a678722b2b3


People who touched revisions under test:
  Alex Deucher 
  Chris Wilson 
  Christian König 
  Clemens Ladisch 
  Dave Airlie 
  Fabio Estevam 
  Felipe Balbi 
  Hyungwon Hwang 
  Imre Deak 
  Inki Dae 
  Jani Nikula 
  Jason Lee Cragg 
  Joonyoung Shim 
  Lee Jones 
  Linus Torvalds 
  Michael Karcher 
  Michel Dänzer 
  Oded Gabbay 
  Roger Tseng 
  Rui Wang 
  Steven Rostedt 
  Takashi Iwai 
  Takashi Sakamoto 
  Tony Luck 


jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  pass
 build-i386-rumpuserxen   pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-xl-pvh-amd  fail
 test-amd64-i386-rhel6hvm-amd pass
 test-amd64-i386-qemut-rhel6hvm-amd   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64pass
 test-amd64-i386-xl-qemut-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  fail
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-rumpuserxen-amd64   pass
 test-amd64-amd64-xl-qemut-win7-amd64 fail
 test-amd64-i386-xl-qemut-win7-amd64  fail
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-

Re: [Xen-devel] [PATCH v2] fix QEMU build on Xen/ARM

[Don Slutz]

On 01/23/15 07:19, Stefano Stabellini wrote:
> xen_get_vmport_regs_pfn should take a xen_pfn_t argument, not an
> unsigned long argument (in fact xen_pfn_t is defined as uint64_t on
> ARM).
> 
> Also use xc_hvm_param_get instead of the deprecated xc_get_hvm_param.
> 
> Signed-off-by: Stefano Stabellini 
> 
> ---
> 

I have tested this on x86_64 with a xen that has
HVM_PARAM_VMPORT_REGS_PFN defined.

And the change looks good to me, so

Reviewed-by: Don Slutz 

   -Don Slutz

> Changes in v2:
> - properly handle return codes and set *vmport_regs_pfn before returning.
> 
> diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
> index 519696f..38f29fb 100644
> --- a/include/hw/xen/xen_common.h
> +++ b/include/hw/xen/xen_common.h
> @@ -168,14 +168,19 @@ void xen_shutdown_fatal_error(const char *fmt, ...) 
> GCC_FMT_ATTR(1, 2);
>  
>  #ifdef HVM_PARAM_VMPORT_REGS_PFN
>  static inline int xen_get_vmport_regs_pfn(XenXC xc, domid_t dom,
> -  unsigned long *vmport_regs_pfn)
> +  xen_pfn_t *vmport_regs_pfn)
>  {
> -return xc_get_hvm_param(xc, dom, HVM_PARAM_VMPORT_REGS_PFN,
> -vmport_regs_pfn);
> +int rc;
> +uint64_t value;
> +rc = xc_hvm_param_get(xc, dom, HVM_PARAM_VMPORT_REGS_PFN, &value);
> +if (rc >= 0) {
> +*vmport_regs_pfn = (xen_pfn_t) value;
> +}
> +return rc;
>  }
>  #else
>  static inline int xen_get_vmport_regs_pfn(XenXC xc, domid_t dom,
> -  unsigned long *vmport_regs_pfn)
> +  xen_pfn_t *vmport_regs_pfn)
>  {
>  return -ENOSYS;
>  }
> 

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

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

[xen . org]

flight 33640 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33640/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf   5 xen-build fail REGR. vs. 33480
 test-amd64-i386-freebsd10-amd64 11 guest-localmigrate fail REGR. vs. 33480
 test-amd64-i386-rhel6hvm-intel  5 xen-bootfail REGR. vs. 33480
 test-amd64-i386-xl-win7-amd64 10 guest-localmigrate   fail REGR. vs. 33480
 test-amd64-amd64-xl-win7-amd64 10 guest-localmigrate  fail REGR. vs. 33480
 test-amd64-amd64-xl-winxpsp3 10 guest-localmigratefail REGR. vs. 33480
 test-amd64-i386-freebsd10-i386 11 guest-localmigrate  fail REGR. vs. 33480
 test-amd64-i386-xl-winxpsp3-vcpus1 10 guest-localmigrate  fail REGR. vs. 33480
 test-amd64-i386-xl-winxpsp3  10 guest-localmigratefail REGR. vs. 33480

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 10 guest-localmigrate fail REGR. vs. 
33480
 test-amd64-i386-xl-qemuu-ovmf-amd64 10 guest-localmigrate fail REGR. vs. 33480
 test-amd64-i386-xl-qemuu-debianhvm-amd64 10 guest-localmigrate fail REGR. vs. 
33480
 test-amd64-i386-xl-qemuu-win7-amd64 10 guest-localmigrate fail REGR. vs. 33480
 test-amd64-amd64-xl-qemuu-win7-amd64 10 guest-localmigrate fail REGR. vs. 33480
 test-amd64-amd64-xl-qemuu-winxpsp3 10 guest-localmigrate  fail REGR. vs. 33480
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 guest-localmigrate fail REGR. vs. 
33480
 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 guest-localmigrate fail REGR. vs. 33480
 test-amd64-i386-xl-qemuu-winxpsp3 10 guest-localmigrate   fail REGR. vs. 33480
 test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 33480

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start  fail  never pass
 test-amd64-i386-libvirt   9 guest-start  fail   never pass
 test-amd64-amd64-libvirt  9 guest-start  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start fail never pass
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd   9 guest-start  fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop  fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass

version targeted for testing:
 qemuu699eae17b841e6784dc3864bf357e26bff1e9dfe
baseline version:
 qemuu1e42c353469cb58ca4f3b450eea4211af7d0b147


People who touched revisions under test:
  Benjamin Herrenschmidt 
  Gerd Hoffmann 
  Paolo Bonzini 
  Paul Durrant 
  Peter Maydell 
  Stefano Stabellini 


jobs:
 build-amd64  pass
 build-armhf  fail
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  blocked 
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  blocked 
 test-amd64-i386-xl   pass
 test-amd64-amd64-xl-pvh-amd  fail
 test-amd64-i386-rhel6hvm-amd pass
 test-amd64-i386-qemut-rhel6hvm-amd   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64pass
 test-amd64-i386-xl-qemut-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64fail
 test-amd64-i386-xl-qemuu-debianhvm-amd64 fail
 test-amd64-i386-freebsd10-amd64  fail
 test-amd64-amd64-xl-qemuu-ovmf-amd64 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail
 test-amd64-amd64-xl-qemut-

[Xen-devel] [xen-4.4-testing test] 33668: tolerable FAIL - PUSHED

[xen . org]

flight 33668 xen-4.4-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33668/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl5 xen-bootfail pass in 33614
 test-amd64-i386-rhel6hvm-intel  5 xen-boot fail in 33614 pass in 33668

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 33563
 test-amd64-i386-xl-qemut-win7-amd64 7 windows-install fail in 33614 like 33563

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-i386-libvirt   9 guest-start  fail   never pass
 test-armhf-armhf-libvirt  9 guest-start  fail   never pass
 test-amd64-amd64-libvirt  9 guest-start  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start fail never pass
 build-i386-rumpuserxen6 xen-buildfail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop   fail  never pass
 build-amd64-rumpuserxen   6 xen-buildfail   never pass
 test-armhf-armhf-xl  10 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop   fail   never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check fail  never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop   fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop  fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop   fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/checkfail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop   fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop   fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop  fail never pass

version targeted for testing:
 xen  4da395fe75c24cceb9337b64d4c96e8c2da29b2e
baseline version:
 xen  30f10d4d2b102bd7184b84c9cc3d2246f060706a


People who touched revisions under test:
  Ian Campbell 
  Julien Grall 


jobs:
 build-amd64-xend pass
 build-i386-xend  pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  fail
 build-i386-rumpuserxen   fail
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   fail
 test-amd64-i386-rhel6hvm-amd pass
 test-amd64-i386-qemut-rhel6hvm-amd   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64pass
 test-amd64-i386-xl-qemut-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-rumpuserxen-amd64   blocked 
 test-amd64-amd64-xl-qemut-win7-amd64 fail
 test-amd64-i386-xl-qemut-win7-amd64  fail
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-a

Re: [Xen-devel] [PATCH v1 13/21] Ovmf/Xen: move arch specific hypercall implementation to XenHypercallLib

[Stefano Stabellini]

On Fri, 23 Jan 2015, Ard Biesheuvel wrote:
> For future ARM/AArch64 support in the XenBus code, move the implementation
> of hypercall invocation to a dedicated library. The use of a library rather
> than just an arch specific source in XenBusDxe.inf allows us to move the
> constructor dependency on the gXenInfoGuid HOB to the library implementation.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 

Although it looks vaguely OK, I think it would be much more readable if
you broke this patch down, separating out the code movements from the
changes to the interface (like dropping the XENBUS_DEVICE* parameter).



>  OvmfPkg/Include/Library/XenHypercallLib.h  |  78 ++
>  .../XenHypercallLib}/Ia32/hypercall.nasm   |   6 +-
>  .../XenHypercallLib}/X64/hypercall.nasm|   6 +-
>  .../XenHypercallLib/XenHypercallLibCommon.c|  63 +++
>  .../Library/XenHypercallLib/XenHypercallLibIntel.c |  77 ++
>  .../XenHypercallLib/XenHypercallLibIntel.inf   |  52 +
>  OvmfPkg/OvmfPkg.dec|   4 +
>  OvmfPkg/OvmfPkgIa32.dsc|   1 +
>  OvmfPkg/OvmfPkgIa32X64.dsc |   1 +
>  OvmfPkg/OvmfPkgX64.dsc |   1 +
>  OvmfPkg/XenBusDxe/EventChannel.c   |  14 +--
>  OvmfPkg/XenBusDxe/GrantTable.c |   6 +-
>  OvmfPkg/XenBusDxe/XenBusDxe.c  |  51 +++--
>  OvmfPkg/XenBusDxe/XenBusDxe.h  |   1 -
>  OvmfPkg/XenBusDxe/XenBusDxe.inf|  11 +-
>  OvmfPkg/XenBusDxe/XenHypercall.c   | 118 
> -
>  OvmfPkg/XenBusDxe/XenHypercall.h   | 113 
>  OvmfPkg/XenBusDxe/XenStore.c   |   6 +-
>  18 files changed, 338 insertions(+), 271 deletions(-)
>  create mode 100644 OvmfPkg/Include/Library/XenHypercallLib.h
>  rename OvmfPkg/{XenBusDxe => Library/XenHypercallLib}/Ia32/hypercall.nasm 
> (81%)
>  rename OvmfPkg/{XenBusDxe => Library/XenHypercallLib}/X64/hypercall.nasm 
> (78%)
>  create mode 100644 OvmfPkg/Library/XenHypercallLib/XenHypercallLibCommon.c
>  create mode 100644 OvmfPkg/Library/XenHypercallLib/XenHypercallLibIntel.c
>  create mode 100644 OvmfPkg/Library/XenHypercallLib/XenHypercallLibIntel.inf
>  delete mode 100644 OvmfPkg/XenBusDxe/XenHypercall.c
>  delete mode 100644 OvmfPkg/XenBusDxe/XenHypercall.h
> 
> diff --git a/OvmfPkg/Include/Library/XenHypercallLib.h 
> b/OvmfPkg/Include/Library/XenHypercallLib.h
> new file mode 100644
> index ..6c94cbf7f2e6
> --- /dev/null
> +++ b/OvmfPkg/Include/Library/XenHypercallLib.h
> @@ -0,0 +1,78 @@
> +/** @file
> +  Xen Hypercall Library definition
> +
> +Copyright (c) 2014, Linaro Ltd. All rights reserved.
> +This program and the accompanying materials are licensed and made available 
> under
> +the terms and conditions of the BSD License that accompanies this 
> distribution.
> +The full text of the license may be found at
> +http://opensource.org/licenses/bsd-license.php.
> +
> +THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
> +
> +**/
> +
> +#ifndef __XEN_HYPERCALL_LIB_H_
> +#define __XEN_HYPERCALL_LIB_H_
> +
> +/**
> +  Return the value of the HVM parameter Index.
> +
> +  @param Index  The parameter to get, e.g. HVM_PARAM_STORE_EVTCHN.
> +
> +  @return   The value of the asked parameter or 0 in case of error.
> +**/
> +UINT64
> +XenHypercallHvmGetParam (
> +  UINT32 Index
> +  );
> +
> +/**
> +  Hypercall to do different operation on the memory.
> +
> +  @param Operation  The operation number, e.g. XENMEM_add_to_physmap.
> +  @param Arguments  The arguments associated to the operation.
> +
> +  @return  Return the return value from the hypercall, 0 in case of success
> +   otherwise, an error code.
> +**/
> +INTN
> +XenHypercallMemoryOp (
> +  IN UINTN Operation,
> +  IN OUT VOID *Arguments
> +  );
> +
> +/**
> +  Do an operation on the event channels.
> +
> +  @param Operation  The operation number, e.g. EVTCHNOP_send.
> +  @param Arguments  The argument associated to the operation.
> +
> +  @return  Return the return value from the hypercall, 0 in case of success
> +   otherwise, an error code.
> +**/
> +INTN
> +XenHypercallEventChannelOp (
> +  IN INTN Operation,
> +  IN OUT VOID *Arguments
> +  );
> +
> +/**
> +  This function will put the two arguments in the right place (registers) and
> +  invoke the hypercall identified by HypercallID.
> +
> +  @param HypercallIDThe symbolic ID of the hypercall to be invoked
> +  @param Arg1   First argument.
> +  @param Arg2   Second argument.
> +
> +  @return   Return 0 if success otherwise it return an errno.
> +**/
> +INTN
> +EFIAPI
> +XenHypercall2 (
> +  IN INTN HypercallID,
> +  IN OU

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

[xen . org]

flight 33649 xen-4.5-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33649/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-winxpsp3  5 xen-boot fail REGR. vs. 33603

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl5 xen-boot fail   like 33603

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start  fail  never pass
 test-armhf-armhf-libvirt  9 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-amd   9 guest-start  fail   never pass
 test-armhf-armhf-xl  10 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt   9 guest-start  fail   never pass
 test-amd64-amd64-libvirt  9 guest-start  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop   fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop  fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop   fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop   fail never pass
 test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop   fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop   fail   never pass

version targeted for testing:
 xen  3367ca8e821eb8e3e48d82d661b18dc0e2c49918
baseline version:
 xen  9ae1853b0394ddc68bb53d6dab2326f743399fa8


People who touched revisions under test:
  Jan Beulich 


jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  pass
 build-i386-rumpuserxen   pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   fail
 test-amd64-amd64-xl-pvh-amd  fail
 test-amd64-i386-rhel6hvm-amd pass
 test-amd64-i386-qemut-rhel6hvm-amd   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64pass
 test-amd64-i386-xl-qemut-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-rumpuserxen-amd64   pass
 test-amd64-amd64-xl-qemut-win7-amd64 fail
 test-amd64-i386-xl-qemut-win7-amd64  fail
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-win7-amd64   fail
 test-amd64-i386-xl-win7-amd64fail
 test-amd64-i386-xl-credit2   pass
 test-amd64-i386-freebsd10-i386  

Re: [Xen-devel] [PATCH v1 12/21] Ovmf/Xen: fix pointer to int cast in XenBusDxe

[Stefano Stabellini]

On Fri, 23 Jan 2015, Ard Biesheuvel wrote:
> On ARM, xen_pfn_t is 64 bits but the size of a pointer is only
> 32 bits, so casting between them needs to go via (UINTN)
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 

Reviewed-by: Stefano Stabellini 


>  OvmfPkg/XenBusDxe/GrantTable.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/OvmfPkg/XenBusDxe/GrantTable.c b/OvmfPkg/XenBusDxe/GrantTable.c
> index 37d3bf786c64..cc6f045c9827 100644
> --- a/OvmfPkg/XenBusDxe/GrantTable.c
> +++ b/OvmfPkg/XenBusDxe/GrantTable.c
> @@ -160,7 +160,7 @@ XenGrantTableInit (
>  Parameters.domid = DOMID_SELF;
>  Parameters.idx = Index;
>  Parameters.space = XENMAPSPACE_grant_table;
> -Parameters.gpfn = (((xen_pfn_t) GrantTable) >> EFI_PAGE_SHIFT) + Index;
> +Parameters.gpfn = (((xen_pfn_t)(UINTN) GrantTable) >> EFI_PAGE_SHIFT) + 
> Index;
>  ReturnCode = XenHypercallMemoryOp (Dev, XENMEM_add_to_physmap, 
> &Parameters);
>  if (ReturnCode != 0) {
>DEBUG ((EFI_D_ERROR, "Xen GrantTable, add_to_physmap hypercall error: 
> %d\n", ReturnCode));
> @@ -182,7 +182,7 @@ XenGrantTableDeinit (
>  
>for (Index = NR_GRANT_FRAMES - 1; Index >= 0; Index--) {
>  Parameters.domid = DOMID_SELF;
> -Parameters.gpfn = (((xen_pfn_t) GrantTable) >> EFI_PAGE_SHIFT) + Index;
> +Parameters.gpfn = (((xen_pfn_t)(UINTN) GrantTable) >> EFI_PAGE_SHIFT) + 
> Index;
>  DEBUG ((EFI_D_INFO, "Xen GrantTable, removing %X\n", Parameters.gpfn));
>  ReturnCode = XenHypercallMemoryOp (Dev, XENMEM_remove_from_physmap, 
> &Parameters);
>  if (ReturnCode != 0) {
> -- 
> 1.8.3.2
> 

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

[Xen-devel] [rumpuserxen test] 33658: all pass - PUSHED

[xen . org]

flight 33658 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33658/

Perfect :-)
All tests in this flight passed
version targeted for testing:
 rumpuserxen  598ceb54916b2a87c8646c96a23e1e03b2e65e59
baseline version:
 rumpuserxen  0f482c4b52ea2c43bcb80da5450009dcb0c76781


People who touched revisions under test:
  Antti Kantee 
  Martin Lucina 


jobs:
 build-amd64  pass
 build-i386   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  pass
 build-i386-rumpuserxen   pass
 test-amd64-amd64-rumpuserxen-amd64   pass
 test-amd64-i386-rumpuserxen-i386 pass



sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
http://www.chiark.greenend.org.uk/~xensrcts/logs

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


Pushing revision :

+ branch=rumpuserxen
+ revision=598ceb54916b2a87c8646c96a23e1e03b2e65e59
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push rumpuserxen 
598ceb54916b2a87c8646c96a23e1e03b2e65e59
+ branch=rumpuserxen
+ revision=598ceb54916b2a87c8646c96a23e1e03b2e65e59
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock 
']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=rumpuserxen
+ xenbranch=xen-unstable
+ '[' xrumpuserxen = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osst...@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : https://github.com/rumpkernel/rumprun-xen
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 
'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 
'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osst...@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.rumpuserxen
++ : daily-cron.rump

[Xen-devel] [linux-3.10 test] 33671: regressions - FAIL

[xen . org]

flight 33671 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33671/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-libvirt   5 xen-boot  fail REGR. vs. 26303
 test-amd64-i386-rhel6hvm-intel  5 xen-bootfail REGR. vs. 26303
 test-amd64-i386-qemut-rhel6hvm-intel  5 xen-boot  fail REGR. vs. 26303
 test-amd64-i386-xl-multivcpu  5 xen-boot  fail REGR. vs. 26303
 test-amd64-i386-xl5 xen-boot  fail REGR. vs. 26303
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot  fail REGR. vs. 26303
 test-amd64-amd64-xl   5 xen-boot  fail REGR. vs. 26303
 test-amd64-i386-xl-qemut-win7-amd64  5 xen-boot   fail REGR. vs. 26303
 test-amd64-i386-freebsd10-i386  5 xen-bootfail REGR. vs. 26303
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  5 xen-boot  fail REGR. vs. 26303
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-bootfail REGR. vs. 26303
 test-amd64-i386-xl-win7-amd64  5 xen-boot fail REGR. vs. 26303
 test-amd64-i386-xl-qemuu-win7-amd64  5 xen-boot   fail REGR. vs. 26303
 test-amd64-i386-xl-qemut-winxpsp3  5 xen-boot fail REGR. vs. 26303
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install   fail REGR. vs. 26303
 test-amd64-amd64-xl-qemuu-ovmf-amd64  5 xen-boot  fail REGR. vs. 26303
 test-amd64-i386-pair  8 xen-boot/dst_host fail REGR. vs. 26303
 test-amd64-i386-pair  7 xen-boot/src_host fail REGR. vs. 26303
 test-amd64-i386-xl-winxpsp3   5 xen-boot  fail REGR. vs. 26303
 test-amd64-i386-xl-qemuu-winxpsp3  5 xen-boot fail REGR. vs. 26303
 test-amd64-amd64-pair   12 debian-fixup/dst_host fail in 33577 REGR. vs. 26303
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 7 windows-install fail in 33577 REGR. 
vs. 26261
 test-amd64-amd64-xl-qemut-winxpsp3 7 windows-install fail in 33577 REGR. vs. 
26303
 test-amd64-i386-xl-credit2 6 leak-check/basis(6) fail in 33466 REGR. vs. 26303
 test-amd64-i386-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail in 33567 REGR. 
vs. 26303

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-bootfail pass in 33577
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot  fail pass in 33466
 test-amd64-i386-xl-credit25 xen-bootfail pass in 33466
 test-amd64-i386-xl-qemuu-ovmf-amd64  5 xen-boot fail pass in 33567
 test-amd64-amd64-xl-qemuu-winxpsp3  5 xen-boot  fail pass in 33521
 test-amd64-amd64-xl-win7-amd64  5 xen-boot  fail pass in 33625
 test-amd64-amd64-xl-qemut-win7-amd64  5 xen-bootfail pass in 33625
 test-amd64-amd64-pair 8 xen-boot/dst_host   fail pass in 33625
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  5 xen-bootfail pass in 33577
 test-amd64-amd64-xl-winxpsp3  5 xen-bootfail pass in 33577
 test-amd64-amd64-xl-qemut-winxpsp3  5 xen-boot  fail pass in 33625
 test-amd64-amd64-xl-sedf  7 debian-install fail in 33577 pass in 33671
 test-amd64-amd64-libvirt  7 debian-install fail in 33577 pass in 33671
 test-amd64-amd64-xl-qemut-win7-amd64 7 windows-install fail in 33577 pass in 
33567
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot   fail in 33577 pass in 33671
 test-amd64-i386-qemuu-rhel6hvm-intel 3 host-install(3) broken in 33466 pass in 
33671
 test-amd64-amd64-xl-sedf  8 debian-fixup   fail in 33466 pass in 33671
 test-amd64-amd64-pair 7 xen-boot/src_host  fail in 33466 pass in 33671
 test-amd64-amd64-libvirt  5 xen-boot   fail in 33521 pass in 33671
 test-amd64-amd64-xl-sedf  5 xen-boot   fail in 33625 pass in 33671
 test-amd64-amd64-pair   11 debian-install/dst_host fail in 33625 pass in 33577

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-rumpuserxen-i386  5 xen-boot fail blocked in 26303
 test-amd64-amd64-xl-pvh-intel  5 xen-bootfail blocked in 26303
 test-amd64-amd64-xl-pvh-amd   7 debian-install   fail blocked in 26303
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot   fail REGR. vs. 26303
 test-amd64-i386-rhel6hvm-amd  5 xen-bootfail like 28907-bisect
 test-amd64-i386-qemut-rhel6hvm-amd  5 xen-boot  fail like 28953-bisect
 test-amd64-i386-freebsd10-amd64  5 xen-boot fail like 29368-bisect
 test-amd64-amd64-xl-qemut-debianhvm-amd64  5 xen-bootfail blocked in 26303
 test-amd64-i386-xl-qemut-debianhvm-amd64  5 xen-boot fail blocked in 26303
 test-amd64-i386-xl-qemuu-debianhvm-amd64  5 xen-boot fail blocked in 26303
 test-amd64-amd64-rumpuserxen-amd64  5 xen-boot   fail blocked in 26303
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  5 xen-bootfail blocked in 26303
 test-amd

Re: [Xen-devel] [PATCH v1 11/21] Ovmf/Xen: move Xen interface version to

[Stefano Stabellini]

On Fri, 23 Jan 2015, Ard Biesheuvel wrote:
> Tiancore has its private copy of the Xen headers, and all drivers
> that depend on it should use the same Xen interface version, so
> let's move the #define to xen.h itself.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 

Reviewed-by: Stefano Stabellini 


>  OvmfPkg/Include/IndustryStandard/Xen/xen.h | 5 +
>  OvmfPkg/XenBusDxe/XenBusDxe.h  | 5 -
>  OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.h  | 4 
>  3 files changed, 5 insertions(+), 9 deletions(-)
> 
> diff --git a/OvmfPkg/Include/IndustryStandard/Xen/xen.h 
> b/OvmfPkg/Include/IndustryStandard/Xen/xen.h
> index 79697fcb6152..1cd7ab3ab136 100644
> --- a/OvmfPkg/Include/IndustryStandard/Xen/xen.h
> +++ b/OvmfPkg/Include/IndustryStandard/Xen/xen.h
> @@ -27,6 +27,11 @@
>  #ifndef __XEN_PUBLIC_XEN_H__
>  #define __XEN_PUBLIC_XEN_H__
>  
> +//
> +// Xen interface version used by Tianocore
> +//
> +#define __XEN_INTERFACE_VERSION__ 0x00040400
> +
>  #include "xen-compat.h"
>  
>  #if defined(MDE_CPU_IA32) || defined(MDE_CPU_X64)
> diff --git a/OvmfPkg/XenBusDxe/XenBusDxe.h b/OvmfPkg/XenBusDxe/XenBusDxe.h
> index 11640223ebf4..80253b7d1ca9 100644
> --- a/OvmfPkg/XenBusDxe/XenBusDxe.h
> +++ b/OvmfPkg/XenBusDxe/XenBusDxe.h
> @@ -19,11 +19,6 @@
>  #include 
>  
>  //
> -// Xen interface version used
> -//
> -#define  __XEN_INTERFACE_VERSION__ 0x00040400
> -
> -//
>  // Libraries
>  //
>  #include 
> diff --git a/OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.h 
> b/OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.h
> index e5b1b5f4b90d..c0b62c4f38ca 100644
> --- a/OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.h
> +++ b/OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.h
> @@ -18,10 +18,6 @@
>  
>  #include 
>  
> -//
> -// Xen interface version used
> -//
> -#define __XEN_INTERFACE_VERSION__ 0x00040400
>  #define xen_mb() MemoryFence()
>  #define xen_rmb() MemoryFence()
>  #define xen_wmb() MemoryFence()
> -- 
> 1.8.3.2
> 

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

[Xen-devel] [xen-unstable test] 33637: tolerable FAIL - PUSHED

[xen . org]

flight 33637 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33637/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-win7-amd64  5 xen-boot  fail pass in 33581
 test-amd64-amd64-rumpuserxen-amd64  5 xen-boot fail in 33581 pass in 33637

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 33542

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt   9 guest-start  fail   never pass
 test-amd64-amd64-libvirt  9 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel  9 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd   9 guest-start  fail   never pass
 test-armhf-armhf-libvirt  9 guest-start  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start fail never pass
 test-armhf-armhf-xl  10 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stopfail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop   fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop   fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop   fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop  fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop  fail in 33581 never pass

version targeted for testing:
 xen  7106c691a6332cffab4037186d1caa3012ae051e
baseline version:
 xen  0d2879062076329038860f873dcbeb6f55bd4917


People who touched revisions under test:
  Andrew Cooper 
  Anthony PERARD 
  Daniel De Graaf 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Jim Fehlig 
  Julien Grall 
  Paul Durrant 
  Samuel Thibault 
  Stefano Stabellini 
  Tim Deegan 
  Wei Liu 


jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-oldkern  pass
 build-i386-oldkern   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  pass
 build-i386-rumpuserxen   pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-xl-pvh-amd  fail
 test-amd64-i386-rhel6hvm-amd pass
 test-amd64-i386-qemut-rhel6hvm-amd   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64pass
 test-amd64-i386-xl-qemut-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-rumpuserxen-amd64   pass
 test-amd64-amd64-xl-qemut-win7-amd64 fail
 test-amd64-i386-xl-qemut-win7-amd64  fail
 test-amd64-am

[Xen-devel] [linux-3.14 test] 33634: regressions - trouble: broken/fail/pass

[xen . org]

flight 33634 linux-3.14 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33634/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-pvh-intel  5 xen-boot fail REGR. vs. 33341
 test-amd64-amd64-xl   5 xen-boot  fail REGR. vs. 33341
 test-amd64-i386-rumpuserxen-i386  5 xen-boot  fail REGR. vs. 33341
 test-amd64-i386-libvirt   5 xen-boot  fail REGR. vs. 33341
 test-amd64-i386-xl-multivcpu  5 xen-boot  fail REGR. vs. 33341
 test-amd64-i386-qemut-rhel6hvm-intel  5 xen-boot  fail REGR. vs. 33341
 test-amd64-i386-freebsd10-amd64  5 xen-boot   fail REGR. vs. 33341
 test-amd64-i386-xl-qemut-debianhvm-amd64  5 xen-boot  fail REGR. vs. 33341
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot  fail REGR. vs. 33341
 test-amd64-amd64-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail REGR. vs. 33341
 test-amd64-i386-xl5 xen-boot  fail REGR. vs. 33341
 test-amd64-i386-xl-qemuu-debianhvm-amd64  5 xen-boot  fail REGR. vs. 33341
 test-amd64-i386-xl-qemuu-ovmf-amd64  5 xen-boot   fail REGR. vs. 33341
 test-amd64-i386-xl-win7-amd64  5 xen-boot fail REGR. vs. 33341
 test-amd64-i386-xl-qemut-winxpsp3  5 xen-boot fail REGR. vs. 33341
 test-amd64-i386-freebsd10-i386  5 xen-bootfail REGR. vs. 33341
 test-amd64-i386-xl-qemuu-win7-amd64  5 xen-boot   fail REGR. vs. 33341
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  5 xen-boot  fail REGR. vs. 33341
 test-amd64-amd64-xl-qemut-winxpsp3  5 xen-bootfail REGR. vs. 33341
 test-amd64-i386-xl-qemut-win7-amd64  5 xen-boot   fail REGR. vs. 33341
 test-amd64-amd64-pair 8 xen-boot/dst_host fail REGR. vs. 33341
 test-amd64-amd64-xl-qemut-win7-amd64  5 xen-boot  fail REGR. vs. 33341
 test-amd64-i386-xl-winxpsp3   5 xen-boot  fail REGR. vs. 33341
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot  fail REGR. vs. 33341
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  5 xen-boot fail REGR. vs. 33341
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  5 xen-boot  fail REGR. vs. 33341
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-bootfail REGR. vs. 33341
 test-amd64-i386-pair  8 xen-boot/dst_host fail REGR. vs. 33341
 test-amd64-i386-pair  7 xen-boot/src_host fail REGR. vs. 33341
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install fail REGR. vs. 33341
 test-amd64-i386-xl-qemuu-winxpsp3  6 leak-check/basis(6)  fail REGR. vs. 33341
 test-amd64-amd64-xl-winxpsp3  5 xen-boot  fail REGR. vs. 33341
 test-amd64-amd64-rumpuserxen-amd64 7 rumpuserxen-demo-setup fail in 33462 
REGR. vs. 33341
 test-amd64-amd64-xl-win7-amd64 7 windows-install fail in 33462 REGR. vs. 33341
 test-amd64-amd64-xl-pvh-amd   7 debian-install   fail in 33560 REGR. vs. 33341
 test-amd64-i386-rhel6hvm-amd 6 leak-check/basis(6) fail in 33560 REGR. vs. 
33341
 test-amd64-i386-xl-credit27 debian-install   fail in 33494 REGR. vs. 33341
 test-amd64-i386-qemuu-rhel6hvm-amd 7 redhat-install fail in 33494 REGR. vs. 
33341
 test-amd64-i386-qemut-rhel6hvm-amd 7 redhat-install fail in 33580 REGR. vs. 
33341

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-rumpuserxen-amd64  5 xen-boot  fail pass in 33462
 test-amd64-amd64-xl-pvh-amd   5 xen-bootfail pass in 33560
 test-amd64-amd64-libvirt  5 xen-bootfail pass in 33494
 test-amd64-i386-xl-credit25 xen-bootfail pass in 33494
 test-amd64-i386-rhel6hvm-amd  5 xen-bootfail pass in 33560
 test-amd64-i386-qemut-rhel6hvm-amd  5 xen-boot  fail pass in 33580
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot  fail pass in 33494
 test-amd64-amd64-xl-win7-amd64  5 xen-boot  fail pass in 33462
 test-amd64-amd64-xl-qemut-debianhvm-amd64  5 xen-boot   fail pass in 33580
 test-amd64-amd64-xl-qemuu-ovmf-amd64  5 xen-boot   fail in 33462 pass in 33634
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 3 host-install(3) broken in 33462 
pass in 33634
 test-amd64-amd64-pair 7 xen-boot/src_host  fail in 33462 pass in 33634
 test-amd64-amd64-xl-qemuu-winxpsp3  5 xen-boot fail in 33462 pass in 33634
 test-amd64-i386-xl-qemuu-winxpsp3  5 xen-boot  fail in 33462 pass in 33634
 test-armhf-armhf-xl  12 guest-start.2  fail in 33494 pass in 33634

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot  fail REGR. vs. 33341
 test-amd64-amd64-xl-sedf  5 xen-boot  fail REGR. vs. 33341
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot   fail REGR. vs. 33341
 test-amd64-i386-rhel6hvm-intel  5 xen-boot fail like 33296
 test-amd64-

Re: [Xen-devel] -EINTR return in domain_relinquish_resources

[Konrad Rzeszutek Wilk]

On Fri, Jan 23, 2015 at 04:03:55PM +, Jan Beulich wrote:
> >>> On 23.01.15 at 16:46,  wrote:
> > Subject: [PATCH] domain: In vcpu_destroy_pagetables we can return -ERESTART
> >  instead of -EINTR
> > 
> > which has the side effect that domain_relinquish_resources will stop
> > and return to user-space -EINTR - which it is not equipped to deal with.
> 
> The title read wrong, especially on its own, as it appears to
> state the inverse thing of what you do in the patch. Perhaps
> 
> x86: vcpu_destroy_pagetables() must not return -EINTR
> 
> with the initial part of the description adjusted accordingly?
> 
> > +/*
> > + * The put_page_and_type_preemptible is liable to return -EINTR. Other
> > + * callers of it filter the -EINTR to whatever they deem applicable - 
> > in
> > + * this case we MUST do it as the caller of this function will return 
> > the
> > + * error code to userspace. And userspace for domain destruction 
> > expects
> > + * -EAGAIN (domain_relinquish_resources converts ERESTART to -EAGAIN).
> > + */
> 
> This is still misleading, as it kind of implies that the function has only
> that one caller. Don't talk about domain_relinquish_resources() and
> EAGAIN at all.

Right. I somehow managed to miss the other caller of vcpu_destroy_pagetables.

Please see following patch:

>From 3ace309c61805bae546378e37553913231e43cec Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk 
Date: Thu, 22 Jan 2015 11:34:21 -0500
Subject: [PATCH] domain: vcpu_destroy_pagetables() must not return -EINTR

.. otherwise it has the side effect that: domain_relinquish_resources
will stop and will return to user-space with -EINTR which it is not
equipped to deal with that error code; or vcpu_reset - which will
ignore it and convert the error to -ENOMEM..

The preemption mechanism we have for domain destruction is to return
-EAGAIN (and then user-space calls the hypercall again) and as such we need
to catch the case of:

domain_relinquish_resources
  ->vcpu_destroy_pagetables
-> put_page_and_type_preemptible
   -> __put_page_type
   returns -EINTR

and convert it to the proper type. For:

XEN_DOMCTL_setvcpucontext
 -> vcpu_reset
   -> vcpu_destroy_pagetables

we need to return -ERESTART otherwise we end up returning -ENOMEM.

There are also other callers of vcpu_destroy_pagetables: arch_vcpu_reset
(vcpu_reset) are:
 - hvm_s3_suspend (asserts on any return code),
 - vlapic_init_sipi_one (asserts on any return code),

Signed-off-by: Konrad Rzeszutek Wilk 
---
v2: Add comment and s/ERESTART/EAGAIN/
v3: Also include the hypercall.
---
 xen/arch/x86/mm.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 6e9c2c0..badbeab 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -2677,6 +2677,13 @@ int vcpu_destroy_pagetables(struct vcpu *v)
 
 v->arch.cr3 = 0;
 
+/*
+ * The put_page_and_type_preemptible is liable to return -EINTR. The
+ * callers of us expect -ERESTART so convert it over.
+ */
+if ( rc == -EINTR )
+rc = -ERESTART;
+
 return rc;
 }
 
-- 
2.1.0

> 
> Jan
> 

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

Re: [Xen-devel] Release Manager for Xen 4.6

[Lars Kurth]

On 23 Jan 2015, at 15:20, Stefano Stabellini  
wrote:

> On Fri, 23 Jan 2015, Konrad Rzeszutek Wilk wrote:
>> On Thu, Jan 22, 2015 at 03:12:08PM -0500, Konrad Rzeszutek Wilk wrote:
>>> Hey,
>>> 
>>> I will becoming more involved in OpenStack to the point that
>>> I cannot see myself wearing the Release Manager hat as well.
>>> 
>>> As such I would like to hand the jacket off to the next 
>>> victi^M^M^Mvolunteer.
>> 
>> And I nominate Wei Liu (if he is up for it of course).
> 
> Nomination seconded

Same from me
Lars
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xen-blk: add myself as maintainer of xen-blk{back/front}

[Konrad Rzeszutek Wilk]

On Fri, Jan 23, 2015 at 05:00:00PM +, David Vrabel wrote:
> On 23/01/15 16:14, Roger Pau Monne wrote:
> > I've done quite a lot of work in blkfront/blkback, and I usually end up
> > looking at the patches, so add myself as maintainer together with Konrad.
> 
> Thanks, Roger.
> 
> I can take care of shovelling the patches onto the xen/tip.git if you
> don't have a kernel.org account.

Please keep in mind that these patches need to go through Jens Axboe as
he is the block maintainer.

So the flow would have to be Roger -> David -> Roger posting GIT PULL To Jens 
-> Jens -> Linus.
> 
> David
> 

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

Re: [Xen-devel] [PATCH v1 03/21] ArmVirtualizationPkg: replace instance of FixedPcdGet()

[Olivier Martin]

Reviewed-By: Olivier Martin 

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: 23 January 2015 15:03
> To: edk2-de...@lists.sourceforge.net; ler...@redhat.com; Olivier
> Martin; roy.fr...@linaro.org; leif.lindh...@linaro.org;
> stefano.stabell...@eu.citrix.com; ian.campb...@citrix.com;
> anthony.per...@citrix.com; christoffer.d...@linaro.org; xen-
> de...@lists.xen.org; ilias.bi...@linaro.org
> Cc: Ard Biesheuvel
> Subject: [PATCH v1 03/21] ArmVirtualizationPkg: replace instance of
> FixedPcdGet()
> 
> This removes an instance of FixedPcdGet () so that the self relocating
> PrePi instance can poke another value into it.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
>  .../ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/Virt.c
> | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git
> a/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatform
> Lib/Virt.c
> b/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatform
> Lib/Virt.c
> index aa4ced4582e8..3e3074af72f1 100644
> ---
> a/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatform
> Lib/Virt.c
> +++
> b/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatform
> Lib/Virt.c
> @@ -96,7 +96,7 @@ ArmPlatformInitializeSystemMemory (
>ASSERT (HobData != NULL);
>*HobData = 0;
> 
> -  DeviceTreeBase = (VOID *)(UINTN)FixedPcdGet64
> (PcdDeviceTreeInitialBaseAddress);
> +  DeviceTreeBase = (VOID *)(UINTN)PcdGet64
> (PcdDeviceTreeInitialBaseAddress);
>ASSERT (DeviceTreeBase != NULL);
> 
>//
> --
> 1.8.3.2
> 





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

Re: [Xen-devel] [PATCH v1 02/21] ArmVirtualizationPkg: add GICv3 detection to VirtFdtDxe

[Olivier Martin]

Reviewed-By: Olivier Martin 

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: 23 January 2015 15:03
> To: edk2-de...@lists.sourceforge.net; ler...@redhat.com; Olivier
> Martin; roy.fr...@linaro.org; leif.lindh...@linaro.org;
> stefano.stabell...@eu.citrix.com; ian.campb...@citrix.com;
> anthony.per...@citrix.com; christoffer.d...@linaro.org; xen-
> de...@lists.xen.org; ilias.bi...@linaro.org
> Cc: Ard Biesheuvel
> Subject: [PATCH v1 02/21] ArmVirtualizationPkg: add GICv3 detection to
> VirtFdtDxe
> 
> This adds support for detecting the presence of a GICv3 interrupt
> controller from the device tree, and recording its distributor
> base address in a PCD.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
>  .../ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c  | 19
> +++
>  1 file changed, 19 insertions(+)
> 
> diff --git
> a/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c
> b/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c
> index 4e4f608923d3..8953f78f5fe4 100644
> --- a/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c
> +++ b/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c
> @@ -46,6 +46,7 @@ typedef enum {
>PropertyTypeTimer,
>PropertyTypePsci,
>PropertyTypeFwCfg,
> +  PropertyTypeGicV3,
>  } PROPERTY_TYPE;
> 
>  typedef struct {
> @@ -62,6 +63,7 @@ STATIC CONST PROPERTY CompatibleProperties[] = {
>{ PropertyTypeTimer,   "arm,armv8-timer" },
>{ PropertyTypePsci,"arm,psci-0.2"},
>{ PropertyTypeFwCfg,   "qemu,fw-cfg-mmio"},
> +  { PropertyTypeGicV3,   "arm,gic-v3"  },
>{ PropertyTypeUnknown, ""}
>  };
> 
> @@ -256,6 +258,23 @@ InitializeVirtFdtDxe (
>DEBUG ((EFI_D_INFO, "Found GIC @ 0x%Lx/0x%Lx\n", DistBase,
> CpuBase));
>break;
> 
> +case PropertyTypeGicV3:
> +  //
> +  // The GIC v3 DT binding describes a series of at least 3
> physical base
> +  // addresses, but we are only interested in the first one, which
> is the
> +  // distributor interface. (We use the system register CPU
> interface, not
> +  // the MMIO one)
> +  //
> +  ASSERT (Len >= 16);
> +
> +  DistBase = fdt64_to_cpu (((UINT64 *)RegProp)[0]);
> +  ASSERT (DistBase < MAX_UINT32);
> +
> +  PcdSet32 (PcdGicDistributorBase, (UINT32)DistBase);
> +
> +  DEBUG ((EFI_D_INFO, "Found GIC v3 distributor @ 0x%Lx\n",
> DistBase));
> +  break;
> +
>  case PropertyTypeRtc:
>ASSERT (Len == 16);
> 
> --
> 1.8.3.2
> 





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

Re: [Xen-devel] [PATCH v1 01/21] ArmPkg: allow HYP timer interrupt to be omitted

[Olivier Martin]

Reviewed-By: Olivier Martin 

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: 23 January 2015 15:03
> To: edk2-de...@lists.sourceforge.net; ler...@redhat.com; Olivier
> Martin; roy.fr...@linaro.org; leif.lindh...@linaro.org;
> stefano.stabell...@eu.citrix.com; ian.campb...@citrix.com;
> anthony.per...@citrix.com; christoffer.d...@linaro.org; xen-
> de...@lists.xen.org; ilias.bi...@linaro.org
> Cc: Ard Biesheuvel
> Subject: [PATCH v1 01/21] ArmPkg: allow HYP timer interrupt to be
> omitted
> 
> The DT binding for the ARM generic timer describes the secure,
> non-secure, virtual and hypervisor timer interrupts, respectively.
> However, under virtualization, only the virtual timer is usable, and
> the device tree may omit the hypervisor timer interrupt. (Other timer
> interrupts cannot be omitted simply due to the fact that the virtual
> timer is listed third)
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
>  ArmPkg/Drivers/TimerDxe/TimerDxe.c | 14
> +++---
>  .../ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c   |  4 ++--
>  2 files changed, 13 insertions(+), 5 deletions(-)
> 
> diff --git a/ArmPkg/Drivers/TimerDxe/TimerDxe.c
> b/ArmPkg/Drivers/TimerDxe/TimerDxe.c
> index d0a819fc2729..1169d426b255 100644
> --- a/ArmPkg/Drivers/TimerDxe/TimerDxe.c
> +++ b/ArmPkg/Drivers/TimerDxe/TimerDxe.c
> @@ -369,7 +369,8 @@ TimerInitialize (
>  {
>EFI_HANDLE  Handle = NULL;
>EFI_STATUS  Status;
> -  UINTN TimerCtrlReg;
> +  UINTN   TimerCtrlReg;
> +  UINT32  TimerHypIntrNum;
> 
>if (ArmIsArchTimerImplemented () == 0) {
>  DEBUG ((EFI_D_ERROR, "ARM Architectural Timer is not available in
> the CPU, hence cann't use this Driver \n"));
> @@ -395,8 +396,15 @@ TimerInitialize (
>Status = gInterrupt->RegisterInterruptSource (gInterrupt, PcdGet32
> (PcdArmArchTimerVirtIntrNum), TimerInterruptHandler);
>ASSERT_EFI_ERROR (Status);
> 
> -  Status = gInterrupt->RegisterInterruptSource (gInterrupt, PcdGet32
> (PcdArmArchTimerHypIntrNum), TimerInterruptHandler);
> -  ASSERT_EFI_ERROR (Status);
> +  //
> +  // The hypervisor timer interrupt may be omitted by implementations
> that
> +  // execute under virtualization.
> +  //
> +  TimerHypIntrNum = PcdGet32 (PcdArmArchTimerHypIntrNum);
> +  if (TimerHypIntrNum != 0) {
> +Status = gInterrupt->RegisterInterruptSource (gInterrupt,
> TimerHypIntrNum, TimerInterruptHandler);
> +ASSERT_EFI_ERROR (Status);
> +  }
> 
>Status = gInterrupt->RegisterInterruptSource (gInterrupt, PcdGet32
> (PcdArmArchTimerSecIntrNum), TimerInterruptHandler);
>ASSERT_EFI_ERROR (Status);
> diff --git
> a/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c
> b/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c
> index 751864d4db9c..4e4f608923d3 100644
> --- a/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c
> +++ b/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c
> @@ -274,7 +274,7 @@ InitializeVirtFdtDxe (
>//  hypervisor timers, in that order.
>//
>InterruptProp = fdt_getprop (DeviceTreeBase, Node, "interrupts",
> &Len);
> -  ASSERT (Len == 48);
> +  ASSERT (Len == 36 || Len == 48);
> 
>SecIntrNum = fdt32_to_cpu (InterruptProp[0].Number)
> + (InterruptProp[0].Type ? 16 : 0);
> @@ -282,7 +282,7 @@ InitializeVirtFdtDxe (
>  + (InterruptProp[1].Type ? 16 : 0);
>VirtIntrNum = fdt32_to_cpu (InterruptProp[2].Number)
>  + (InterruptProp[2].Type ? 16 : 0);
> -  HypIntrNum = fdt32_to_cpu (InterruptProp[3].Number)
> +  HypIntrNum = Len < 48 ? 0 : fdt32_to_cpu
> (InterruptProp[3].Number)
> + (InterruptProp[3].Type ? 16 : 0);
> 
>DEBUG ((EFI_D_INFO, "Found Timer interrupts %d, %d, %d, %d\n",
> --
> 1.8.3.2
> 





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

Re: [Xen-devel] [PATCH] xen-blk: add myself as maintainer of xen-blk{back/front}

[David Vrabel]

On 23/01/15 16:14, Roger Pau Monne wrote:
> I've done quite a lot of work in blkfront/blkback, and I usually end up
> looking at the patches, so add myself as maintainer together with Konrad.

Thanks, Roger.

I can take care of shovelling the patches onto the xen/tip.git if you
don't have a kernel.org account.

David


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

Re: [Xen-devel] [PATCH] xen-blk: add myself as maintainer of xen-blk{back/front}

[Konrad Rzeszutek Wilk]

On Fri, Jan 23, 2015 at 05:14:29PM +0100, Roger Pau Monne wrote:
> I've done quite a lot of work in blkfront/blkback, and I usually end up
> looking at the patches, so add myself as maintainer together with Konrad.
> 
> Signed-off-by: Roger Pau Monné 
> Cc: Konrad Rzeszutek Wilk 

Acked-by: Konrad Rzeszutek Wilk 

Thank you!
> Cc: Boris Ostrovsky 
> Cc: David Vrabel 
> Cc: xen-de...@lists.xenproject.org
> ---
>  MAINTAINERS | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index c721042..96e129c 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -10351,6 +10351,7 @@ F:drivers/pci/*xen*
>  
>  XEN BLOCK SUBSYSTEM
>  M:   Konrad Rzeszutek Wilk 
> +M:   Roger Pau Monné 
>  L:   xen-de...@lists.xenproject.org (moderated for non-subscribers)
>  S:   Supported
>  F:   drivers/block/xen-blkback/*
> -- 
> 1.9.3 (Apple Git-50)
> 

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

Re: [Xen-devel] [OSSTEST PATCH] README.dev: Document how to do a force push.

[Ian Jackson]

Ian Campbell writes ("[OSSTEST PATCH] README.dev: Document how to do a force 
push."):
> Signed-off-by: Ian Campbell 
...
> +Force pushing a branch
> +==
> +
> +As osstest user on test controller
> +$ cd ~/branches/for-$branch.git
> +$ OSSTEST_CONFIG=production-config ./ap-push $branch $revision

This works in ~osstest/testing.git too.

Ian.

>From c9cfea3529c7f75b519a861df6457b9d44b167ac Mon Sep 17 00:00:00 2001
From: Ian Campbell 
Date: Tue, 6 Jan 2015 13:51:17 +
Subject: [OSSTEST PATCH] README.dev: Document how to do a force push.

Signed-off-by: Ian Campbell 
Signed-off-by: Ian Jackson 
---
 README.dev |   13 +
 1 file changed, 13 insertions(+)

diff --git a/README.dev b/README.dev
index eb72659..ed8dcf9 100644
--- a/README.dev
+++ b/README.dev
@@ -123,3 +123,16 @@ initial push works
 When pushing the patches, be sure to make sure that the
 for-$branch.git repo can fast forward to the pushed version (perhaps
 by resetting it).
+
+Force pushing a branch
+==
+
+As osstest user on test controller
+
+$ cd ~/branches/for-$branch.git
+OR
+$ cd ~/testing.git
+
+$ OSSTEST_CONFIG=production-config ./ap-push $branch $revision
+
+NOTE: $revision must be a revision *not* a tag.
-- 
1.7.10.4


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

Re: [Xen-devel] [PATCH] README.dev: Document the usage of stop files

[Ian Jackson]

Ian Campbell writes ("Re: [PATCH] README.dev: Document the usage of stop 
files"):
> I've redone it as below which I think is probably (?) clearer.

Yes, I think it's much clearer, thanks.

Acked-by: Ian Jackson 

> There are  some less useful things you can do like [stuff]
> but that's a bit redundant so I didn't document it.

Yes.

> I think I'm correct that $HOME/testing.git/$branch.stop stops both
> regular flights and bisects?

Yes.

Acked-by: Ian Jackson 

I will accumulate this into a branch of mine, as I now have an
outstanding ovmf patch from Wei which is waiting for a test flight.

Ian.

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

[Xen-devel] [PATCH] x86: use tzcnt instead of bsf

[Jan Beulich]

Following a compiler change done in 2012, make use of the fact that for
non-zero input BSF and TZCNT produce the same numeric result (EFLAGS
setting differs), and that CPUs not knowing of TZCNT will treat the
instruction as BSF (i.e. ignore what looks like a REP prefix to them).
The assumption here is that TZCNT would never have worse performance
than BSF.

Also extend the asm() input in find_first_set_bit() to allow memory
operands.

Signed-off-by: Jan Beulich 
---
Thanks to Andrew for noticing that I forgot to post this for Xen after
a similar change got accepted into the Linux kernel.

--- a/xen/arch/x86/bitops.c
+++ b/xen/arch/x86/bitops.c
@@ -62,7 +62,7 @@ unsigned int __find_first_zero_bit(
 "   je 2f\n\t"
 "   xor -"STR(BITS_PER_LONG/8)"(%2),%3\n\t"
 "   jz 1b\n\t"
-"   bsf %3,%0\n\t"
+"   rep; bsf %3,%0\n\t"
 "   lea -"STR(BITS_PER_LONG/8)"(%2),%2\n\t"
 "2: sub %%ebx,%%edi\n\t"
 "   shl $3,%%edi\n\t"
--- a/xen/arch/x86/hvm/vpic.c
+++ b/xen/arch/x86/hvm/vpic.c
@@ -56,7 +56,7 @@ static int vpic_get_priority(struct hvm_
 return VPIC_PRIO_NONE;
 
 /* prio = ffs(mask ROR vpic->priority_add); */
-asm ( "ror %%cl,%b1 ; bsf %1,%0"
+asm ( "ror %%cl,%b1 ; rep; bsf %1,%0"
   : "=r" (prio) : "q" ((uint32_t)mask), "c" (vpic->priority_add) );
 return prio;
 }
--- a/xen/include/asm-x86/bitops.h
+++ b/xen/include/asm-x86/bitops.h
@@ -382,7 +382,7 @@ static inline unsigned int __scanbit(uns
  */
 static inline unsigned int find_first_set_bit(unsigned long word)
 {
-asm ( "bsf %1,%0" : "=r" (word) : "r" (word) );
+asm ( "rep; bsf %1,%0" : "=r" (word) : "rm" (word) );
 return (unsigned int)word;
 }
 



x86: use tzcnt instead of bsf

Following a compiler change done in 2012, make use of the fact that for
non-zero input BSF and TZCNT produce the same numeric result (EFLAGS
setting differs), and that CPUs not knowing of TZCNT will treat the
instruction as BSF (i.e. ignore what looks like a REP prefix to them).
The assumption here is that TZCNT would never have worse performance
than BSF.

Also extend the asm() input in find_first_set_bit() to allow memory
operands.

Signed-off-by: Jan Beulich 
---
Thanks to Andrew for noticing that I forgot to post this for Xen after
a similar change got accepted into the Linux kernel.

--- a/xen/arch/x86/bitops.c
+++ b/xen/arch/x86/bitops.c
@@ -62,7 +62,7 @@ unsigned int __find_first_zero_bit(
 "   je 2f\n\t"
 "   xor -"STR(BITS_PER_LONG/8)"(%2),%3\n\t"
 "   jz 1b\n\t"
-"   bsf %3,%0\n\t"
+"   rep; bsf %3,%0\n\t"
 "   lea -"STR(BITS_PER_LONG/8)"(%2),%2\n\t"
 "2: sub %%ebx,%%edi\n\t"
 "   shl $3,%%edi\n\t"
--- a/xen/arch/x86/hvm/vpic.c
+++ b/xen/arch/x86/hvm/vpic.c
@@ -56,7 +56,7 @@ static int vpic_get_priority(struct hvm_
 return VPIC_PRIO_NONE;
 
 /* prio = ffs(mask ROR vpic->priority_add); */
-asm ( "ror %%cl,%b1 ; bsf %1,%0"
+asm ( "ror %%cl,%b1 ; rep; bsf %1,%0"
   : "=r" (prio) : "q" ((uint32_t)mask), "c" (vpic->priority_add) );
 return prio;
 }
--- a/xen/include/asm-x86/bitops.h
+++ b/xen/include/asm-x86/bitops.h
@@ -382,7 +382,7 @@ static inline unsigned int __scanbit(uns
  */
 static inline unsigned int find_first_set_bit(unsigned long word)
 {
-asm ( "bsf %1,%0" : "=r" (word) : "r" (word) );
+asm ( "rep; bsf %1,%0" : "=r" (word) : "rm" (word) );
 return (unsigned int)word;
 }
 
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] QEMU 2.2.0 in Xen 4.6

[Eric Shelton]

On Jan 23, 2015 10:10 AM, "Stefano Stabellini" <
stefano.stabell...@eu.citrix.com> wrote:
>
> On Fri, 23 Jan 2015, Ian Campbell wrote:
> > On Fri, 2015-01-23 at 14:42 +, Stefano Stabellini wrote:
> >
> > > HVM guest -(PV)--> QEMU in Dom0 for guest
> > > |
> > > --(emulation)--> QEMU Stubdom-(syscall)->Linux Stubdom---(PV)-->
QEMU Dom0 for stubdom
> >
> > Here, and throughout what you said I think, "QEMU in Dom0 for guest"
> > could equally well be e.g. "blkback in driver domain for guest" likewise
> > the "... for stubdom" too.
> >
> > i.e. the PV backend for the stubdom or the guest doesn't necessarily
> > need to be QEMU and doesn't necessarily need to be in dom0.
>
> Indeed
>

Thank you both.

There is one other thing that would be helpful to understand.  Anthony had
to patch the Linux kernel running in the stubdom to allow memory mapping.
What mappings are needed between dom0 and the stub domain, and between the
stub domain and the HVM guest domain?  I am guessing this comes into play
for the display, as it seems that the dom0 qemu instance is running the VNC
server.

Thanks again,
Eric
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 2/3] grant-table: refactor grant copy to reduce duplicate code

[Jan Beulich]

>>> On 23.01.15 at 11:43,  wrote:
> Much of the grant copy operation is identical for the source and
> destination buffers.  Refactor the code into per-buffer functions.
> 
> Signed-off-by: David Vrabel 

Reviewed-by: Jan Beulich 


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

Re: [Xen-devel] [PATCH v4 02/21] xen: make two memory hypercalls vNUMA-aware

[Jan Beulich]

>>> On 23.01.15 at 17:06,  wrote:
> So the logic of translation now is (take into consideration the second
> point of how we should enforce exact_node flag, I think that flag should
> be preserved if it was requested at the beginning):

Yes, and the code looks right now.

Jan

> +static int translate_vnode_to_pnode(struct domain *d,
> +struct xen_memory_reservation *r,
> +struct memop_args *a)
> +{
> +int rc = 0;
> +unsigned int vnode, pnode;
> +
> +if ( r->mem_flags & XENMEMF_vnode )
> +{
> +a->memflags &= ~MEMF_node(XENMEMF_get_node(r->mem_flags));
> +a->memflags &= ~MEMF_exact_node;
> +
> +read_lock(&d->vnuma_rwlock);
> +if ( d->vnuma )
> +{
> +vnode = XENMEMF_get_node(r->mem_flags);
> +
> +if ( vnode < d->vnuma->nr_vnodes )
> +{
> +pnode = d->vnuma->vnode_to_pnode[vnode];
> +
> +if ( pnode != NUMA_NO_NODE )
> +{
> +a->memflags |= MEMF_node(pnode);
> +if ( r->mem_flags & XENMEMF_exact_node_request )
> +a->memflags |= MEMF_exact_node;
> +}
> +}
> +else
> +rc = -EINVAL;
> +}
> +read_unlock(&d->vnuma_rwlock);
> +}
> +
> +return rc;
> +}
> 
>> Wei.
>> 
>> > Jan




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

[Xen-devel] [PATCH] xen-blk: add myself as maintainer of xen-blk{back/front}

[Roger Pau Monne]

I've done quite a lot of work in blkfront/blkback, and I usually end up
looking at the patches, so add myself as maintainer together with Konrad.

Signed-off-by: Roger Pau Monné 
Cc: Konrad Rzeszutek Wilk 
Cc: Boris Ostrovsky 
Cc: David Vrabel 
Cc: xen-de...@lists.xenproject.org
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index c721042..96e129c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10351,6 +10351,7 @@ F:  drivers/pci/*xen*
 
 XEN BLOCK SUBSYSTEM
 M: Konrad Rzeszutek Wilk 
+M: Roger Pau Monné 
 L: xen-de...@lists.xenproject.org (moderated for non-subscribers)
 S: Supported
 F: drivers/block/xen-blkback/*
-- 
1.9.3 (Apple Git-50)


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

[Xen-devel] [PATCH v2] x86/HVM: Improve EFER validation error messages

[Andrew Cooper]

The previous error message was very little use in identifying the actual
problem after the fact.  Now, hvm_efer_valid() will indicate the issue which
it objects to, which is far more useful for diagnosing issues from logs.

Signed-off-by: Andrew Cooper 
CC: Keir Fraser 
CC: Jan Beulich 

---
v2: Text formatting tweaks suggested by Jan
---
 xen/arch/x86/hvm/hvm.c |   38 ++
 1 file changed, 22 insertions(+), 16 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 2162f97..fd2314e 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1683,8 +1683,9 @@ static int hvm_save_cpu_ctxt(struct domain *d, 
hvm_domain_context_t *h)
 return 0;
 }
 
-static bool_t hvm_efer_valid(const struct vcpu *v, uint64_t value,
- signed int cr0_pg)
+/* Return a string indicating the error, or NULL for valid. */
+static const char * hvm_efer_valid(const struct vcpu *v, uint64_t value,
+   signed int cr0_pg)
 {
 unsigned int ext1_ecx = 0, ext1_edx = 0;
 
@@ -1716,31 +1717,31 @@ static bool_t hvm_efer_valid(const struct vcpu *v, 
uint64_t value,
 if ( (value & EFER_SCE) &&
  !(ext1_edx & cpufeat_mask(X86_FEATURE_SYSCALL)) &&
  (cr0_pg >= 0 || !(value & EFER_LME)) )
-return 0;
+return "SCE without feature";
 
 if ( (value & (EFER_LME | EFER_LMA)) &&
  !(ext1_edx & cpufeat_mask(X86_FEATURE_LM)) )
-return 0;
+return "LME/LMA without feature";
 
 if ( (value & EFER_LMA) && (!(value & EFER_LME) || !cr0_pg) )
-return 0;
+return "LMA/LME/CR0.PG inconsistency";
 
 if ( (value & EFER_NX) && !(ext1_edx & cpufeat_mask(X86_FEATURE_NX)) )
-return 0;
+return "NX without feature";
 
 if ( (value & EFER_SVME) &&
  (!(ext1_ecx & cpufeat_mask(X86_FEATURE_SVM)) ||
   !nestedhvm_enabled(v->domain)) )
-return 0;
+return "SVME without nested virt";
 
 if ( (value & EFER_LMSLE) && !cpu_has_lmsl )
-return 0;
+return "LMSLE without support";
 
 if ( (value & EFER_FFXSE) &&
  !(ext1_edx & cpufeat_mask(X86_FEATURE_FFXSR)) )
-return 0;
+return "FFXSE without feature";
 
-return 1;
+return NULL;
 }
 
 /* These reserved bits in lower 32 remain 0 after any load of CR0 */
@@ -1818,6 +1819,7 @@ static int hvm_load_cpu_ctxt(struct domain *d, 
hvm_domain_context_t *h)
 struct vcpu *v;
 struct hvm_hw_cpu ctxt;
 struct segment_register seg;
+const char *errstr;
 
 /* Which vcpu is this? */
 vcpuid = hvm_load_instance(h);
@@ -1848,10 +1850,11 @@ static int hvm_load_cpu_ctxt(struct domain *d, 
hvm_domain_context_t *h)
 return -EINVAL;
 }
 
-if ( !hvm_efer_valid(v, ctxt.msr_efer, MASK_EXTR(ctxt.cr0, X86_CR0_PG)) )
+errstr = hvm_efer_valid(v, ctxt.msr_efer, MASK_EXTR(ctxt.cr0, X86_CR0_PG));
+if ( errstr )
 {
-printk(XENLOG_G_ERR "HVM%d restore: bad EFER %#" PRIx64 "\n",
-   d->domain_id, ctxt.msr_efer);
+printk(XENLOG_G_ERR "%pv: HVM restore: bad EFER %#" PRIx64 " - %s\n",
+   v, ctxt.msr_efer, errstr);
 return -EINVAL;
 }
 
@@ -2988,13 +2991,16 @@ err:
 int hvm_set_efer(uint64_t value)
 {
 struct vcpu *v = current;
+const char *errstr;
 
 value &= ~EFER_LMA;
 
-if ( !hvm_efer_valid(v, value, -1) )
+errstr = hvm_efer_valid(v, value, -1);
+if ( errstr )
 {
-gdprintk(XENLOG_WARNING, "Trying to set reserved bit in "
- "EFER: %#"PRIx64"\n", value);
+printk(XENLOG_G_WARNING
+   "%pv: Invalid EFER update: %#"PRIx64" -> %#"PRIx64" - %s\n",
+   v, v->arch.hvm_vcpu.guest_efer, value, errstr);
 hvm_inject_hw_exception(TRAP_gp_fault, 0);
 return X86EMUL_EXCEPTION;
 }
-- 
1.7.10.4


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

Re: [Xen-devel] [PATCH] x86/HVM: Improve EFER validation error messages

[Jan Beulich]

>>> On 23.01.15 at 16:53,  wrote:
> The previous error message was very little use in identifying the actual
> problem after the fact.  Now, hvm_efer_valid() will indicate the issue which
> it objects to, which is far more useful for diagnosing issues from logs.

Nice, but ...

> @@ -1848,10 +1850,11 @@ static int hvm_load_cpu_ctxt(struct domain *d, 
> hvm_domain_context_t *h)
>  return -EINVAL;
>  }
>  
> -if ( !hvm_efer_valid(v, ctxt.msr_efer, MASK_EXTR(ctxt.cr0, X86_CR0_PG)) )
> +errstr = hvm_efer_valid(v, ctxt.msr_efer, MASK_EXTR(ctxt.cr0, 
> X86_CR0_PG));
> +if ( errstr )
>  {
> -printk(XENLOG_G_ERR "HVM%d restore: bad EFER %#" PRIx64 "\n",
> -   d->domain_id, ctxt.msr_efer);
> +printk(XENLOG_G_ERR "HVM%d restore: bad EFER %#" PRIx64 " - %s\n",
> +   d->domain_id, ctxt.msr_efer, errstr);

... as you fiddle with it to make it more useful, could you make this
print domain and vcpu ID?

> @@ -2988,13 +2991,16 @@ err:
>  int hvm_set_efer(uint64_t value)
>  {
>  struct vcpu *v = current;
> +const char *errstr;
>  
>  value &= ~EFER_LMA;
>  
> -if ( !hvm_efer_valid(v, value, -1) )
> +errstr = hvm_efer_valid(v, value, -1);
> +if ( errstr )
>  {
> -gdprintk(XENLOG_WARNING, "Trying to set reserved bit in "
> - "EFER: %#"PRIx64"\n", value);
> +printk(XENLOG_G_WARNING
> +   "%pv Invalid EFER update: %#"PRIx64" -> %#"PRIx64" - %s\n",

Perhaps another colon after the %pv?

Jan


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

Re: [Xen-devel] [PATCH v4 02/21] xen: make two memory hypercalls vNUMA-aware

[Wei Liu]

On Fri, Jan 23, 2015 at 03:43:07PM +, Wei Liu wrote:
> On Fri, Jan 23, 2015 at 03:37:51PM +, Jan Beulich wrote:
> > >>> On 23.01.15 at 15:46,  wrote:
> > > On Fri, Jan 23, 2015 at 01:16:19PM +, Jan Beulich wrote:
> > >> >>> On 23.01.15 at 12:13,  wrote:
> > >> > Make XENMEM_increase_reservation and XENMEM_populate_physmap
> > >> > vNUMA-aware.
> > >> > 
> > >> > That is, if guest requests Xen to allocate memory for specific vnode,
> > >> > Xen can translate vnode to pnode using vNUMA information of that guest.
> > >> > 
> > >> > XENMEMF_vnode is introduced for the guest to mark the node number is in
> > >> > fact virtual node number and should be translated by Xen.
> > >> > 
> > >> > XENFEAT_memory_op_vnode_supported is introduced to indicate that Xen is
> > >> > able to translate virtual node to physical node.
> > >> > 
> > >> > Signed-off-by: Wei Liu 
> > >> > Acked-by: Jan Beulich 
> > >> 
> > >> I'm afraid there's another change needed for this to hold:
> > >> 
> > >> > --- a/xen/common/memory.c
> > >> > +++ b/xen/common/memory.c
> > >> > @@ -692,6 +692,50 @@ out:
> > >> >  return rc;
> > >> >  }
> > >> >  
> > >> > +static int translate_vnode_to_pnode(struct domain *d,
> > >> > +struct xen_memory_reservation *r,
> > >> > +struct memop_args *a)
> > >> > +{
> > >> > +int rc = 0;
> > >> > +unsigned int vnode, pnode;
> > >> > +
> > >> > +/*
> > >> > + * Note: we don't strictly require non-supported bits set to zero,
> > >> > + * so we may have exact_vnode bit set for old guests that don't
> > >> > + * support vNUMA.
> > >> > + *
> > >> > + * To distinguish spurious vnode request v.s. real one, check if
> > >> > + * d->vnuma exists.
> > >> > + */
> > >> > +if ( r->mem_flags & XENMEMF_vnode )
> > >> > +{
> > >> > +read_lock(&d->vnuma_rwlock);
> > >> > +if ( d->vnuma )
> > >> 
> > >> if r->mem_flags has XENMEMF_vnode set but d->vnuma is NULL,
> > >> you need to clear the node from the flags.
> > >> 
> > > 
> > > As said in the comment, we don't seem to enforce non-supported bits set
> > > to zero (IIRC you told me that). So an old guest that sets XENMEMF_vnode
> > > by accident will get its other flags cleared if I follow your suggestion.
> > 
> > Which is an acceptable thing to do I think - they called for
> > undefined behavior, and they now get unexpected behavior.
> > Mistaking the virtual node specified for a physical one is certainly
> > less desirable.
> > 
> 
> OK, thanks for clarification.
> 

So the logic of translation now is (take into consideration the second
point of how we should enforce exact_node flag, I think that flag should
be preserved if it was requested at the beginning):

+static int translate_vnode_to_pnode(struct domain *d,
+struct xen_memory_reservation *r,
+struct memop_args *a)
+{
+int rc = 0;
+unsigned int vnode, pnode;
+
+if ( r->mem_flags & XENMEMF_vnode )
+{
+a->memflags &= ~MEMF_node(XENMEMF_get_node(r->mem_flags));
+a->memflags &= ~MEMF_exact_node;
+
+read_lock(&d->vnuma_rwlock);
+if ( d->vnuma )
+{
+vnode = XENMEMF_get_node(r->mem_flags);
+
+if ( vnode < d->vnuma->nr_vnodes )
+{
+pnode = d->vnuma->vnode_to_pnode[vnode];
+
+if ( pnode != NUMA_NO_NODE )
+{
+a->memflags |= MEMF_node(pnode);
+if ( r->mem_flags & XENMEMF_exact_node_request )
+a->memflags |= MEMF_exact_node;
+}
+}
+else
+rc = -EINVAL;
+}
+read_unlock(&d->vnuma_rwlock);
+}
+
+return rc;
+}

> Wei.
> 
> > Jan

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

Re: [Xen-devel] -EINTR return in domain_relinquish_resources

[Jan Beulich]

>>> On 23.01.15 at 16:46,  wrote:
> Subject: [PATCH] domain: In vcpu_destroy_pagetables we can return -ERESTART
>  instead of -EINTR
> 
> which has the side effect that domain_relinquish_resources will stop
> and return to user-space -EINTR - which it is not equipped to deal with.

The title read wrong, especially on its own, as it appears to
state the inverse thing of what you do in the patch. Perhaps

x86: vcpu_destroy_pagetables() must not return -EINTR

with the initial part of the description adjusted accordingly?

> +/*
> + * The put_page_and_type_preemptible is liable to return -EINTR. Other
> + * callers of it filter the -EINTR to whatever they deem applicable - in
> + * this case we MUST do it as the caller of this function will return the
> + * error code to userspace. And userspace for domain destruction expects
> + * -EAGAIN (domain_relinquish_resources converts ERESTART to -EAGAIN).
> + */

This is still misleading, as it kind of implies that the function has only
that one caller. Don't talk about domain_relinquish_resources() and
EAGAIN at all.

Jan


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

Re: [Xen-devel] [PATCH 12/14] xen-blkback: safely unmap grants in case they are still in use

[David Vrabel]

On 23/01/15 15:47, Roger Pau Monné wrote:
> El 23/01/15 a les 15.54, David Vrabel ha escrit:
>> On 23/01/15 14:31, Roger Pau Monné wrote:
>>> El 19/01/15 a les 16.51, David Vrabel ha escrit:
 +  if (invcount) {
 +  ret = gnttab_unmap_refs(unmap, NULL, unmap_pages, 
 invcount);
BUG_ON(ret);
 -  put_free_pages(blkif, unmap_pages, invcount);
 -  invcount = 0;
 +  xen_blkbk_unmap_done(blkif, unmap_pages, invcount);
}
 -  }
 -  if (invcount) {
 -  ret = gnttab_unmap_refs(unmap, NULL, unmap_pages, invcount);
 -  BUG_ON(ret);
 -  put_free_pages(blkif, unmap_pages, invcount);
 +  pages += batch;
 +  num -= batch;
> 
> This should be fixed to at least be (which is still not fully correct,
> but it's better):
> 
> pages += invcount;
> num -= invcount;
> 
> I hope an example will clarify this, suppose we have the following pages
> array:
> 
> pages[0] = persistent grant
> pages[1] = persistent grant
> pages[2] = regular grant
> pages[3] = persistent grant
> pages[4] = regular grant
> 
> And batch is 1. In this case, the unmapped grant will be pages[2], but
> then due to the code below pages will be updated to point to &pages[1],
> which has already been scanned. If this was done correctly pages should
> point to &pages[3]. As said, it's not really a bug, but the loop is
> sub-optimal.

Ah ha.  Thanks for the clear explanation.

gnttab_blkback_unmap_prepare() stops once its been through the whole
batch regardless of whether it filled the array with ops so we don't
check a page twice but this does mean we have a sub-optimal number of ops.

David

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

[Xen-devel] [PATCH] x86/HVM: Improve EFER validation error messages

[Andrew Cooper]

The previous error message was very little use in identifying the actual
problem after the fact.  Now, hvm_efer_valid() will indicate the issue which
it objects to, which is far more useful for diagnosing issues from logs.

Signed-off-by: Andrew Cooper 
CC: Keir Fraser 
CC: Jan Beulich 
---
 xen/arch/x86/hvm/hvm.c |   38 ++
 1 file changed, 22 insertions(+), 16 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 2162f97..62ffbe5 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1683,8 +1683,9 @@ static int hvm_save_cpu_ctxt(struct domain *d, 
hvm_domain_context_t *h)
 return 0;
 }
 
-static bool_t hvm_efer_valid(const struct vcpu *v, uint64_t value,
- signed int cr0_pg)
+/* Return a string indiciating the error, or NULL for valid. */
+static const char * hvm_efer_valid(const struct vcpu *v, uint64_t value,
+   signed int cr0_pg)
 {
 unsigned int ext1_ecx = 0, ext1_edx = 0;
 
@@ -1716,31 +1717,31 @@ static bool_t hvm_efer_valid(const struct vcpu *v, 
uint64_t value,
 if ( (value & EFER_SCE) &&
  !(ext1_edx & cpufeat_mask(X86_FEATURE_SYSCALL)) &&
  (cr0_pg >= 0 || !(value & EFER_LME)) )
-return 0;
+return "SCE without feature";
 
 if ( (value & (EFER_LME | EFER_LMA)) &&
  !(ext1_edx & cpufeat_mask(X86_FEATURE_LM)) )
-return 0;
+return "LME/LMA without feature";
 
 if ( (value & EFER_LMA) && (!(value & EFER_LME) || !cr0_pg) )
-return 0;
+return "LMA/LME/CR0.PG inconsistency";
 
 if ( (value & EFER_NX) && !(ext1_edx & cpufeat_mask(X86_FEATURE_NX)) )
-return 0;
+return "NX without feature";
 
 if ( (value & EFER_SVME) &&
  (!(ext1_ecx & cpufeat_mask(X86_FEATURE_SVM)) ||
   !nestedhvm_enabled(v->domain)) )
-return 0;
+return "SVME without nested virt";
 
 if ( (value & EFER_LMSLE) && !cpu_has_lmsl )
-return 0;
+return "LMSLE without support";
 
 if ( (value & EFER_FFXSE) &&
  !(ext1_edx & cpufeat_mask(X86_FEATURE_FFXSR)) )
-return 0;
+return "FFXSE without feature";
 
-return 1;
+return NULL;
 }
 
 /* These reserved bits in lower 32 remain 0 after any load of CR0 */
@@ -1818,6 +1819,7 @@ static int hvm_load_cpu_ctxt(struct domain *d, 
hvm_domain_context_t *h)
 struct vcpu *v;
 struct hvm_hw_cpu ctxt;
 struct segment_register seg;
+const char *errstr;
 
 /* Which vcpu is this? */
 vcpuid = hvm_load_instance(h);
@@ -1848,10 +1850,11 @@ static int hvm_load_cpu_ctxt(struct domain *d, 
hvm_domain_context_t *h)
 return -EINVAL;
 }
 
-if ( !hvm_efer_valid(v, ctxt.msr_efer, MASK_EXTR(ctxt.cr0, X86_CR0_PG)) )
+errstr = hvm_efer_valid(v, ctxt.msr_efer, MASK_EXTR(ctxt.cr0, X86_CR0_PG));
+if ( errstr )
 {
-printk(XENLOG_G_ERR "HVM%d restore: bad EFER %#" PRIx64 "\n",
-   d->domain_id, ctxt.msr_efer);
+printk(XENLOG_G_ERR "HVM%d restore: bad EFER %#" PRIx64 " - %s\n",
+   d->domain_id, ctxt.msr_efer, errstr);
 return -EINVAL;
 }
 
@@ -2988,13 +2991,16 @@ err:
 int hvm_set_efer(uint64_t value)
 {
 struct vcpu *v = current;
+const char *errstr;
 
 value &= ~EFER_LMA;
 
-if ( !hvm_efer_valid(v, value, -1) )
+errstr = hvm_efer_valid(v, value, -1);
+if ( errstr )
 {
-gdprintk(XENLOG_WARNING, "Trying to set reserved bit in "
- "EFER: %#"PRIx64"\n", value);
+printk(XENLOG_G_WARNING
+   "%pv Invalid EFER update: %#"PRIx64" -> %#"PRIx64" - %s\n",
+   v, v->arch.hvm_vcpu.guest_efer, value, errstr);
 hvm_inject_hw_exception(TRAP_gp_fault, 0);
 return X86EMUL_EXCEPTION;
 }
-- 
1.7.10.4


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

Re: [Xen-devel] [PATCH v4 02/21] xen: make two memory hypercalls vNUMA-aware

[Wei Liu]

On Fri, Jan 23, 2015 at 03:37:51PM +, Jan Beulich wrote:
> >>> On 23.01.15 at 15:46,  wrote:
> > On Fri, Jan 23, 2015 at 01:16:19PM +, Jan Beulich wrote:
> >> >>> On 23.01.15 at 12:13,  wrote:
> >> > Make XENMEM_increase_reservation and XENMEM_populate_physmap
> >> > vNUMA-aware.
> >> > 
> >> > That is, if guest requests Xen to allocate memory for specific vnode,
> >> > Xen can translate vnode to pnode using vNUMA information of that guest.
> >> > 
> >> > XENMEMF_vnode is introduced for the guest to mark the node number is in
> >> > fact virtual node number and should be translated by Xen.
> >> > 
> >> > XENFEAT_memory_op_vnode_supported is introduced to indicate that Xen is
> >> > able to translate virtual node to physical node.
> >> > 
> >> > Signed-off-by: Wei Liu 
> >> > Acked-by: Jan Beulich 
> >> 
> >> I'm afraid there's another change needed for this to hold:
> >> 
> >> > --- a/xen/common/memory.c
> >> > +++ b/xen/common/memory.c
> >> > @@ -692,6 +692,50 @@ out:
> >> >  return rc;
> >> >  }
> >> >  
> >> > +static int translate_vnode_to_pnode(struct domain *d,
> >> > +struct xen_memory_reservation *r,
> >> > +struct memop_args *a)
> >> > +{
> >> > +int rc = 0;
> >> > +unsigned int vnode, pnode;
> >> > +
> >> > +/*
> >> > + * Note: we don't strictly require non-supported bits set to zero,
> >> > + * so we may have exact_vnode bit set for old guests that don't
> >> > + * support vNUMA.
> >> > + *
> >> > + * To distinguish spurious vnode request v.s. real one, check if
> >> > + * d->vnuma exists.
> >> > + */
> >> > +if ( r->mem_flags & XENMEMF_vnode )
> >> > +{
> >> > +read_lock(&d->vnuma_rwlock);
> >> > +if ( d->vnuma )
> >> 
> >> if r->mem_flags has XENMEMF_vnode set but d->vnuma is NULL,
> >> you need to clear the node from the flags.
> >> 
> > 
> > As said in the comment, we don't seem to enforce non-supported bits set
> > to zero (IIRC you told me that). So an old guest that sets XENMEMF_vnode
> > by accident will get its other flags cleared if I follow your suggestion.
> 
> Which is an acceptable thing to do I think - they called for
> undefined behavior, and they now get unexpected behavior.
> Mistaking the virtual node specified for a physical one is certainly
> less desirable.
> 

OK, thanks for clarification.

Wei.

> Jan

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

Re: [Xen-devel] [PATCH v2 2/3] xen/arm: Add new driver for R-Car Gen2 UART

[Oleksandr Tyshchenko]

Hi, Julien.

I created a new patch set (v3) and pushed.

Also I created a standalone patch according to your suggestion above:
http://lists.xen.org/archives/html/xen-devel/2015-01/msg02964.html
I checked it on Lager board on current master.


On Thu, Jan 22, 2015 at 8:33 PM, Oleksandr Tyshchenko <
oleksandr.tyshche...@globallogic.com> wrote:

> On Thu, Jan 22, 2015 at 8:09 PM, Julien Grall 
> wrote:
> > On 22/01/15 17:43, Oleksandr Tyshchenko wrote:
> >> On Thu, Jan 22, 2015 at 7:27 PM, Oleksandr Tyshchenko
> >>  wrote:
> >>> On Thu, Jan 22, 2015 at 7:02 PM, Julien Grall 
> wrote:
>  On 22/01/15 16:55, Oleksandr Tyshchenko wrote:
> > On Thu, Jan 22, 2015 at 6:49 PM, Julien Grall <
> julien.gr...@linaro.org> wrote:
> >> On 22/01/15 16:44, Oleksandr Tyshchenko wrote:
> >>> I understand, then I will implement local delay func in uart driver
> >>> based on READ_SYSREG64(CNTPCT_EL0).
> >>
> >> Unless I miss something, udelay should work in your case even if the
> >> xen_init_time is not called.
> > Unfortunately, no. If I understand correctly the var "cpu_khz" (used
> > in ticks_to_ns()) is initialized in init_xen_time().
> 
>  Hrm, right. I looked too quickly to the function.
> 
>  I don't like the idea to use READ_SYSREG64(CNTPCT_EL0) in the UART
> drivers.
> 
>  Does the udelay necessary here? If yes, maybe we should either split
> the
>  xen_init_time in 2 parts or create a udelay_tick function to use when
>  timer is not set.
> 
>  I'm not sure what is the best one.
> 
>  Regards,
> 
>  --
>  Julien Grall
> >>>
> >>> According to the TRM for this family we need to add delay after
> >>> changing baudrate before continuing init sequence.
> >>> I tried without udelay and it is worked fine. But, if the TRM says we
> >>> need to follow this.
> >>>
> >>> --
> >>>
> >>> Oleksandr Tyshchenko | Embedded Dev
> >>> GlobalLogic
> >>> www.globallogic.com
> >>
> >> I would prefer a first variant. In xen_init_time_1() initialize
> >> "cpu_khz" and "boot_count" only.
> >>
> >>  cpu_khz = READ_SYSREG32(CNTFRQ_EL0) / 1000;
> >>  boot_count = READ_SYSREG64(CNTPCT_EL0);
> >>
> >> In xen_init_time_2() perform all initialization as it was done for
> >> this moment and correct "cpu_khz" if node is present.
> >>
> >> What do you think?
> >>
> >
> > The clock-frequency property is usually present when CNTFRQ_EL0 is
> > invalid. So the udelay won't work correctly for those board.
> >
> > Also, some platform may need to have specific initialization for timer
> > before been able to access it. (see platform_init_time).
> >
> > So we need to move at least to move preinit_xen_time:
> > platform_init()
> > read property clock-frequency
> > cpu_khz = ...
> > boot_count = ...
> >
> > init_xen_time would contain:
> > retrieve IRQs
> > print messages
> >
> > Regards,
> >
> > --
> > Julien Grall
>
> It is clear. I will try.
> Thank you
>
>
>
> --
>
> Oleksandr Tyshchenko | Embedded Dev
> GlobalLogic
> www.globallogic.com
>



-- 

Oleksandr Tyshchenko | Embedded Dev
GlobalLogic
www.globallogic.com

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

[Xen-devel] [RFC PATCH v1] xen/arm: split the init_xen_time() in 2 parts

[Oleksandr Tyshchenko]

Create preinit_xen_time() and move to it minimum required
subset of operations needed to properly initialized
cpu_khz and boot_count vars. This is allow us to use udelay()
immediately after the call.

Signed-off-by: Oleksandr Tyshchenko 
CC: Julien Grall 
---
 xen/arch/arm/setup.c   |  2 ++
 xen/arch/arm/time.c| 71 --
 xen/include/xen/time.h |  1 +
 3 files changed, 48 insertions(+), 26 deletions(-)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index f49569d..dbd7d5a 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -743,6 +743,8 @@ void __init start_xen(unsigned long boot_phys_offset,
 
 init_IRQ();
 
+preinit_xen_time();
+
 dt_uart_init();
 console_init_preirq();
 console_init_ring();
diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
index 455f217..b2560db 100644
--- a/xen/arch/arm/time.c
+++ b/xen/arch/arm/time.c
@@ -61,25 +61,56 @@ unsigned int timer_get_irq(enum timer_ppi ppi)
 return muldiv64(ns, 1000 * cpu_khz, SECONDS(1));
 }
 
-/* Set up the timer on the boot CPU */
-int __init init_xen_time(void)
+static __init struct dt_device_node *find_timer_node(void)
+{
+   static const struct dt_device_match timer_ids[] __initconst =
+   {
+   DT_MATCH_TIMER,
+   { /* sentinel */ },
+   };
+
+   return dt_find_matching_node(NULL, timer_ids);
+}
+
+/* Set up the timer on the boot CPU (early init function) */
+int __init preinit_xen_time(void)
 {
-static const struct dt_device_match timer_ids[] __initconst =
-{
-DT_MATCH_TIMER,
-{ /* sentinel */ },
-};
 struct dt_device_node *dev;
 int res;
-unsigned int i;
 u32 rate;
 
-dev = dt_find_matching_node(NULL, timer_ids);
+dev = find_timer_node();
 if ( !dev )
 panic("Unable to find a compatible timer in the device tree");
 
 dt_device_set_used_by(dev, DOMID_XEN);
 
+res = platform_init_time();
+if ( res )
+panic("Timer: Cannot initialize platform timer");
+
+res = dt_property_read_u32(dev, "clock-frequency", &rate);
+if ( res )
+cpu_khz = rate / 1000;
+else
+cpu_khz = READ_SYSREG32(CNTFRQ_EL0) / 1000;
+
+boot_count = READ_SYSREG64(CNTPCT_EL0);
+
+return 0;
+}
+
+/* Set up the timer on the boot CPU (late init function) */
+int __init init_xen_time(void)
+{
+struct dt_device_node *dev;
+int res;
+unsigned int i;
+
+dev = find_timer_node();
+if ( !dev )
+panic("Unable to find a compatible timer in the device tree");
+
 /* Retrieve all IRQs for the timer */
 for ( i = TIMER_PHYS_SECURE_PPI; i < MAX_TIMER_PPI; i++ )
 {
@@ -90,27 +121,15 @@ int __init init_xen_time(void)
 timer_irq[i] = res;
 }
 
-printk("Generic Timer IRQ: phys=%u hyp=%u virt=%u\n",
-   timer_irq[TIMER_PHYS_NONSECURE_PPI],
-   timer_irq[TIMER_HYP_PPI],
-   timer_irq[TIMER_VIRT_PPI]);
-
-res = platform_init_time();
-if ( res )
-panic("Timer: Cannot initialize platform timer");
-
 /* Check that this CPU supports the Generic Timer interface */
 if ( !cpu_has_gentimer )
 panic("CPU does not support the Generic Timer v1 interface");
 
-res = dt_property_read_u32(dev, "clock-frequency", &rate);
-if ( res )
-cpu_khz = rate / 1000;
-else
-cpu_khz = READ_SYSREG32(CNTFRQ_EL0) / 1000;
-
-boot_count = READ_SYSREG64(CNTPCT_EL0);
-printk("Using generic timer at %lu KHz\n", cpu_khz);
+printk("Generic Timer IRQ: phys=%u hyp=%u virt=%u Freq: %lu KHz\n",
+   timer_irq[TIMER_PHYS_NONSECURE_PPI],
+   timer_irq[TIMER_HYP_PPI],
+   timer_irq[TIMER_VIRT_PPI],
+   cpu_khz);
 
 return 0;
 }
diff --git a/xen/include/xen/time.h b/xen/include/xen/time.h
index 709501f..fc49f71 100644
--- a/xen/include/xen/time.h
+++ b/xen/include/xen/time.h
@@ -12,6 +12,7 @@
 #include 
 
 extern int init_xen_time(void);
+extern int preinit_xen_time(void);
 extern void cstate_restore_tsc(void);
 
 extern unsigned long cpu_khz;
-- 
1.9.1


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

Re: [Xen-devel] [PATCH 12/14] xen-blkback: safely unmap grants in case they are still in use

[Roger Pau Monné]

El 23/01/15 a les 15.54, David Vrabel ha escrit:
> On 23/01/15 14:31, Roger Pau Monné wrote:
>> El 19/01/15 a les 16.51, David Vrabel ha escrit:
>>> From: Jenny Herbert 
>>>
>>> +static void xen_blkbk_unmap(struct xen_blkif *blkif,
>>> +struct grant_page *pages[],
>>> +int num)
>>> +{
>>> +   struct gnttab_unmap_grant_ref unmap[BLKIF_MAX_SEGMENTS_PER_REQUEST];
>>> +   struct page *unmap_pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
>>> +   unsigned int invcount = 0;
>>> +   int ret;
>>> +
>>> +   while (num) {
>>> +   unsigned int batch = min(num, BLKIF_MAX_SEGMENTS_PER_REQUEST);
>>> +   
>>> +   invcount = xen_blkbk_unmap_prepare(blkif, pages, batch,
>>> +  unmap, unmap_pages);
>>
>> I would add:
>>
>> BUG_ON(invcount != batch);
> 
> I'm confused.  Surely invcount < batch is valid if one or more pages
> within this batch are persistently mapped?

Yes, my bad, see below.

> 
>>> +   if (invcount) {
>>> +   ret = gnttab_unmap_refs(unmap, NULL, unmap_pages, 
>>> invcount);
>>> BUG_ON(ret);
>>> -   put_free_pages(blkif, unmap_pages, invcount);
>>> -   invcount = 0;
>>> +   xen_blkbk_unmap_done(blkif, unmap_pages, invcount);
>>> }
>>> -   }
>>> -   if (invcount) {
>>> -   ret = gnttab_unmap_refs(unmap, NULL, unmap_pages, invcount);
>>> -   BUG_ON(ret);
>>> -   put_free_pages(blkif, unmap_pages, invcount);
>>> +   pages += batch;
>>> +   num -= batch;

This should be fixed to at least be (which is still not fully correct,
but it's better):

pages += invcount;
num -= invcount;

I hope an example will clarify this, suppose we have the following pages
array:

pages[0] = persistent grant
pages[1] = persistent grant
pages[2] = regular grant
pages[3] = persistent grant
pages[4] = regular grant

And batch is 1. In this case, the unmapped grant will be pages[2], but
then due to the code below pages will be updated to point to &pages[1],
which has already been scanned. If this was done correctly pages should
point to &pages[3]. As said, it's not really a bug, but the loop is
sub-optimal.

Roger.


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

Re: [Xen-devel] -EINTR return in domain_relinquish_resources

[Konrad Rzeszutek Wilk]

On Fri, Jan 23, 2015 at 03:34:51PM +, Jan Beulich wrote:
> >>> On 23.01.15 at 15:46,  wrote:
> > On 23/01/15 14:32, Konrad Rzeszutek Wilk wrote:
> >> On Fri, Jan 23, 2015 at 09:11:25AM +, Jan Beulich wrote:
> >> On 22.01.15 at 17:38,  wrote:
>  On Thu, Jan 22, 2015 at 10:00:35AM +, Jan Beulich wrote:
>  On 21.01.15 at 22:27,  wrote:
> >> As I was looking at some of the XSA I realized that the
> >> call-chain of:
> >>
> >>  domain_relinquish_resources
> >>->vcpu_destroy_pagetables
> >>  -> put_page_and_type_preemptible
> >> -> __put_page_type
> >>returns -EINTR
> >> [...]
> >>  b). Or should the hypervisor convert the -EINTR to -ERESTART
> >>  (or -EAGAIN) - which most of the code (see users of
> >>  get_page_type_preemptible) do right now?
> > This one, in vcpu_destroy_pagetables(). I'm afraid I overlooked
> > this when adding the preemption capability here.
>  OK. Would this RFC patch be OK? (I can send it off as normal - just
>  want to make sure you are OK with this being put there)
> >>> Conceptually yes, but there are issues:
> >>>
>  From 1558a9870f438df949a8ad09a27825bd35a9f4ea Mon Sep 17 00:00:00 2001
>  From: Konrad Rzeszutek Wilk 
>  Date: Thu, 22 Jan 2015 11:34:21 -0500
>  Subject: [PATCH] domain: In vcpu_destroy_pagetables we can return -EINTR
>   instead of -EAGAIN
> >>> You should stop sending such conversions to EAGAIN. We switched
> >>> to ERESTART, and you (just guessing) taking the patch from an
> >>> older Xen version shouldn't result in this recurring mistake.
> >> Nah, Andrew said in his email EAGAIN so that is what I picked.
> > 
> > EAGAIN was correct for the domain_destroy hypercall, at this hypercall
> > explicitly has continuation built into its API via EAGAIN.
> 
> Ouch - I based the comment on code resulting from a patch I
> didn't send out yet (largely because Konrad indicated issues with
> XEN_DOMCTL_destroydomain that I'd need to look into in more
> detail before doing so), doing away with the tool stack based
> continuations. Yet based on what domain_kill() does with
> domain_relinquish_resources()'s return value, it should
> nevertheless be -ERESTART here to ease future changes.

OK :-)


>From ac642805a96261f518fbba7d47f3ca38c950b3c8 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk 
Date: Thu, 22 Jan 2015 11:34:21 -0500
Subject: [PATCH] domain: In vcpu_destroy_pagetables we can return -ERESTART
 instead of -EINTR

which has the side effect that domain_relinquish_resources will stop
and return to user-space -EINTR - which it is not equipped to deal with.
The preemption mechanism we have to domain destruction is to return
-EAGAIN and as such we need to catch the case of:

domain_relinquish_resources
  ->vcpu_destroy_pagetables
-> put_page_and_type_preemptible
   -> __put_page_type
   returns -EINTR

and convert it to the proper type.

Signed-off-by: Konrad Rzeszutek Wilk 
---
v2: Add comment and s/ERESTART/EAGAIN/
---
 xen/arch/x86/mm.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 6e9c2c0..5452c01 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -2677,6 +2677,16 @@ int vcpu_destroy_pagetables(struct vcpu *v)
 
 v->arch.cr3 = 0;
 
+/*
+ * The put_page_and_type_preemptible is liable to return -EINTR. Other
+ * callers of it filter the -EINTR to whatever they deem applicable - in
+ * this case we MUST do it as the caller of this function will return the
+ * error code to userspace. And userspace for domain destruction expects
+ * -EAGAIN (domain_relinquish_resources converts ERESTART to -EAGAIN).
+ */
+if ( rc == -EINTR )
+rc = -ERESTART;
+
 return rc;
 }
 
-- 
2.1.0


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

Re: [Xen-devel] [PATCH v4 02/21] xen: make two memory hypercalls vNUMA-aware

[Jan Beulich]

>>> On 23.01.15 at 15:46,  wrote:
> On Fri, Jan 23, 2015 at 01:16:19PM +, Jan Beulich wrote:
>> >>> On 23.01.15 at 12:13,  wrote:
>> > Make XENMEM_increase_reservation and XENMEM_populate_physmap
>> > vNUMA-aware.
>> > 
>> > That is, if guest requests Xen to allocate memory for specific vnode,
>> > Xen can translate vnode to pnode using vNUMA information of that guest.
>> > 
>> > XENMEMF_vnode is introduced for the guest to mark the node number is in
>> > fact virtual node number and should be translated by Xen.
>> > 
>> > XENFEAT_memory_op_vnode_supported is introduced to indicate that Xen is
>> > able to translate virtual node to physical node.
>> > 
>> > Signed-off-by: Wei Liu 
>> > Acked-by: Jan Beulich 
>> 
>> I'm afraid there's another change needed for this to hold:
>> 
>> > --- a/xen/common/memory.c
>> > +++ b/xen/common/memory.c
>> > @@ -692,6 +692,50 @@ out:
>> >  return rc;
>> >  }
>> >  
>> > +static int translate_vnode_to_pnode(struct domain *d,
>> > +struct xen_memory_reservation *r,
>> > +struct memop_args *a)
>> > +{
>> > +int rc = 0;
>> > +unsigned int vnode, pnode;
>> > +
>> > +/*
>> > + * Note: we don't strictly require non-supported bits set to zero,
>> > + * so we may have exact_vnode bit set for old guests that don't
>> > + * support vNUMA.
>> > + *
>> > + * To distinguish spurious vnode request v.s. real one, check if
>> > + * d->vnuma exists.
>> > + */
>> > +if ( r->mem_flags & XENMEMF_vnode )
>> > +{
>> > +read_lock(&d->vnuma_rwlock);
>> > +if ( d->vnuma )
>> 
>> if r->mem_flags has XENMEMF_vnode set but d->vnuma is NULL,
>> you need to clear the node from the flags.
>> 
> 
> As said in the comment, we don't seem to enforce non-supported bits set
> to zero (IIRC you told me that). So an old guest that sets XENMEMF_vnode
> by accident will get its other flags cleared if I follow your suggestion.

Which is an acceptable thing to do I think - they called for
undefined behavior, and they now get unexpected behavior.
Mistaking the virtual node specified for a physical one is certainly
less desirable.

Jan


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

Re: [Xen-devel] -EINTR return in domain_relinquish_resources

[Jan Beulich]

>>> On 23.01.15 at 15:46,  wrote:
> On 23/01/15 14:32, Konrad Rzeszutek Wilk wrote:
>> On Fri, Jan 23, 2015 at 09:11:25AM +, Jan Beulich wrote:
>> On 22.01.15 at 17:38,  wrote:
 On Thu, Jan 22, 2015 at 10:00:35AM +, Jan Beulich wrote:
 On 21.01.15 at 22:27,  wrote:
>> As I was looking at some of the XSA I realized that the
>> call-chain of:
>>
>>  domain_relinquish_resources
>>->vcpu_destroy_pagetables
>>  -> put_page_and_type_preemptible
>> -> __put_page_type
>>  returns -EINTR
>> [...]
>>  b). Or should the hypervisor convert the -EINTR to -ERESTART
>>  (or -EAGAIN) - which most of the code (see users of
>>  get_page_type_preemptible) do right now?
> This one, in vcpu_destroy_pagetables(). I'm afraid I overlooked
> this when adding the preemption capability here.
 OK. Would this RFC patch be OK? (I can send it off as normal - just
 want to make sure you are OK with this being put there)
>>> Conceptually yes, but there are issues:
>>>
 From 1558a9870f438df949a8ad09a27825bd35a9f4ea Mon Sep 17 00:00:00 2001
 From: Konrad Rzeszutek Wilk 
 Date: Thu, 22 Jan 2015 11:34:21 -0500
 Subject: [PATCH] domain: In vcpu_destroy_pagetables we can return -EINTR
  instead of -EAGAIN
>>> You should stop sending such conversions to EAGAIN. We switched
>>> to ERESTART, and you (just guessing) taking the patch from an
>>> older Xen version shouldn't result in this recurring mistake.
>> Nah, Andrew said in his email EAGAIN so that is what I picked.
> 
> EAGAIN was correct for the domain_destroy hypercall, at this hypercall
> explicitly has continuation built into its API via EAGAIN.

Ouch - I based the comment on code resulting from a patch I
didn't send out yet (largely because Konrad indicated issues with
XEN_DOMCTL_destroydomain that I'd need to look into in more
detail before doing so), doing away with the tool stack based
continuations. Yet based on what domain_kill() does with
domain_relinquish_resources()'s return value, it should
nevertheless be -ERESTART here to ease future changes.

Jan


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

[Xen-devel] [PATCH v3 0/3] arm: introduce basic Renesas R-Car Gen2 platform support

[Oleksandr Tyshchenko]

Changes in v3:
1. Rewrite uart driver code to use start_tx/stop_tx callbacks.
2. Uncomment udelay after setup desired baudrate.
3. Call platform_get_irq() before ioremap_nocache().

Changes in v2:
1. Remove timer initialization from board file (timer shold be initialized in 
u-boot)
2. Coding style fixes.
3. Change ioremap_attr() to ioremap_nocache().
4. Other misc fixes.

The following patch series adds basic support needed for R-Car Gen2 boards.
Verified on Xen 4.5.0 stable on Lager board with and without early_printk.
Procedure needed to run Xen on Lager board is described on Xen wiki:
http://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/Lager

Iurii Konovalenko (1):
  xen/arm: Introduce support for Renesas R-Car Gen2 platform

Oleksandr Tyshchenko (2):
  xen/arm: Add R-Car Gen2 support for early printk
  xen/arm: Add new driver for R-Car Gen2 UART

 config/arm32.mk|   1 +
 docs/misc/arm/early-printk.txt |   1 +
 xen/arch/arm/Rules.mk  |   4 +
 xen/arch/arm/arm32/debug-rcar2.inc |  49 +
 xen/arch/arm/platforms/Makefile|   1 +
 xen/arch/arm/platforms/shmobile.c  |  71 +++
 xen/drivers/char/Makefile  |   1 +
 xen/drivers/char/rcar2-uart.c  | 366 +
 xen/include/asm-arm/rcar2-uart.h   | 107 +++
 9 files changed, 601 insertions(+)
 create mode 100644 xen/arch/arm/arm32/debug-rcar2.inc
 create mode 100644 xen/arch/arm/platforms/shmobile.c
 create mode 100644 xen/drivers/char/rcar2-uart.c
 create mode 100644 xen/include/asm-arm/rcar2-uart.h

-- 
1.9.1


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

[Xen-devel] [PATCH v3 1/3] xen/arm: Add R-Car Gen2 support for early printk

[Oleksandr Tyshchenko]

Signed-off-by: Oleksandr Tyshchenko 
Reviewed-by: Julien Grall 
---
 docs/misc/arm/early-printk.txt |   1 +
 xen/arch/arm/Rules.mk  |   4 ++
 xen/arch/arm/arm32/debug-rcar2.inc |  49 +
 xen/include/asm-arm/rcar2-uart.h   | 107 +
 4 files changed, 161 insertions(+)
 create mode 100644 xen/arch/arm/arm32/debug-rcar2.inc
 create mode 100644 xen/include/asm-arm/rcar2-uart.h

diff --git a/docs/misc/arm/early-printk.txt b/docs/misc/arm/early-printk.txt
index 71a0247..1ca2a55 100644
--- a/docs/misc/arm/early-printk.txt
+++ b/docs/misc/arm/early-printk.txt
@@ -19,6 +19,7 @@ where mach is the name of the machine:
   - brcm: printk with 8250 on Broadcom 7445D0 boards with A15 processors.
   - hip04-d01: printk with 8250 on HiSilicon Hip-04 D01
   - seattle: printk with pl011 for AMD Seattle processor
+  - lager: printk with SCIF0 on Renesas R-Car H2 processors
 
 The base address and baud rate is hardcoded in xen/arch/arm/Rules.mk,
 see there when adding support for new machines.
diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
index 4ee51a9..ff02893 100644
--- a/xen/arch/arm/Rules.mk
+++ b/xen/arch/arm/Rules.mk
@@ -109,6 +109,10 @@ ifeq ($(CONFIG_EARLY_PRINTK), seattle)
 EARLY_PRINTK_INC := pl011
 EARLY_UART_BASE_ADDRESS := 0xe101
 endif
+ifeq ($(CONFIG_EARLY_PRINTK), lager)
+EARLY_PRINTK_INC := rcar2
+EARLY_UART_BASE_ADDRESS := 0xe6e6
+endif
 
 ifneq ($(EARLY_PRINTK_INC),)
 EARLY_PRINTK := y
diff --git a/xen/arch/arm/arm32/debug-rcar2.inc 
b/xen/arch/arm/arm32/debug-rcar2.inc
new file mode 100644
index 000..e8d17f3
--- /dev/null
+++ b/xen/arch/arm/arm32/debug-rcar2.inc
@@ -0,0 +1,49 @@
+/*
+ * xen/arch/arm/arm32/debug-rcar2.inc
+ *
+ * R-Car Gen2 specific debug code
+ *
+ * Oleksandr Tyshchenko 
+ * Copyright (C) 2014, Globallogic.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+
+/* R-Car Gen2 UART wait UART to be ready to transmit
+ * rb: register which contains the UART base address
+ * rc: scratch register
+ */
+.macro early_uart_ready rb rc
+1:
+ldrh   \rc, [\rb, #SCIF_SCFSR]   /* <- SCFSR (status register) */
+tst\rc, #SCFSR_TDFE  /* Check TDFE bit */
+beq1b/* Wait for the UART to be ready */
+.endm
+
+/* R-Car Gen2 UART transmit character
+ * rb: register which contains the UART base address
+ * rt: register which contains the character to transmit
+ */
+.macro early_uart_transmit rb rt
+strb   \rt, [\rb, #SCIF_SCFTDR]  /* -> SCFTDR (data 
register) */
+ldrh   \rt, [\rb, #SCIF_SCFSR]   /* <- SCFSR (status 
register) */
+and\rt, \rt, #(~(SCFSR_TEND | SCFSR_TDFE))   /* Clear TEND and 
TDFE bits */
+strh   \rt, [\rb, #SCIF_SCFSR]   /* -> SCFSR (status 
register) */
+.endm
+
+/*
+ * Local variables:
+ * mode: ASM
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/rcar2-uart.h b/xen/include/asm-arm/rcar2-uart.h
new file mode 100644
index 000..3a5871a
--- /dev/null
+++ b/xen/include/asm-arm/rcar2-uart.h
@@ -0,0 +1,107 @@
+/*
+ * xen/include/asm-arm/rcar2-uart.h
+ *
+ * Common constant definition between early printk and the UART driver
+ * for the R-Car Gen2 UART.
+ *
+ * Oleksandr Tyshchenko 
+ * Copyright (C) 2014, Globallogic.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __ASM_ARM_RCAR2_UART_H
+#define __ASM_ARM_RCAR2_UART_H
+
+#define SCIF_FIFO_MAX_SIZE16
+#define SCIF_CLK_FREQ 14745600
+
+/* Register offsets */
+#define SCIF_SCSMR (0x00)/* Serial mode register   */
+#define SCIF_SCBRR (0x04)/* Bit rate register  */
+#define SCIF_SCSCR (0x08)/* Serial control register*/
+#define SCIF_SCFTDR(0x0C)/* Transmit FIFO data register*/
+#define SCIF_SCFSR (0x10)/* Serial status register */
+#define SCIF_SCFRDR(0x14)/* Receive FIFO data register */
+#define SCIF_SCFCR (0x18)/* FIFO control register

Re: [Xen-devel] [PATCH] README.dev: Document the usage of stop files

[Ian Campbell]

On Fri, 2015-01-23 at 15:20 +, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH] README.dev: Document the usage of stop files"):
> ...
> >  NOTE: $revision must be a revision *not* a tag.
> > +
> > +Temporarily stopping a branch or the entire system
> > +==
> > +
> > +osstest can be paused by dropping a stop file into either the central
> > +$HOME/testing.git or ~/branches/for-$branch.git etc.
> > +
> > +stop   -- stops everything
> > +daily.stop -- stops all regular daily tests
> > +bisects.stop   -- stops all bisections
> > +$branch.stop   -- stops $branch
> > +$xenbranch.stop-- stops everything using $xenbranch
> > +daily.stop -- stops all regular daily tests
> 
> `daily.stop' is mentioned twice here.
> 
> You should probably mention that dropping `stop' into for-$branch.git
> doesn't stop "everything" but only that branch.

I've redone it as below which I think is probably (?) clearer. There are
some less useful things you can do like
$HOME/branches/for-$branch.git/$branch.stop, but that's a bit redundant
so I didn't document it. Likewise I think
$HOME/branches/for-$branch.git/$xenbranch.stop (i.e. stop this branch
iff it is using $xenbranch) isn't terribly helpful.

I think I'm correct that $HOME/testing.git/$branch.stop stops both
regular flights and bisects?

Please could you also take a look at "README.dev: Document how to do a
force push." from
<1420552277-4358-1-git-send-email-ian.campb...@citrix.com>.

8<--

>From 5f4cf7b340828b42f0828a141ad8275eea7b6d22 Mon Sep 17 00:00:00 2001
From: Ian Campbell 
Date: Fri, 23 Jan 2015 15:13:20 +
Subject: [PATCH] README.dev: Document the usage of stop files

Signed-off-by: Ian Campbell 
---
v2: Improve (?)
---
 README.dev | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/README.dev b/README.dev
index 1257649..5e69cb8 100644
--- a/README.dev
+++ b/README.dev
@@ -132,3 +132,37 @@ $ cd ~/branches/for-$branch.git
 $ OSSTEST_CONFIG=production-config ./ap-push $branch $revision
 
 NOTE: $revision must be a revision *not* a tag.
+
+Temporarily stopping a branch or the entire system
+==
+
+osstest can be paused by dropping a stop file into either the central
+$HOME/testing.git or $HOME/branches/for-$branch.git etc.
+
+$HOME/testing.git/stop
+
+  stop everything
+
+$HOME/testing.git/daily.stop
+
+  stops all regular tests
+
+$HOME/testing.git/bisect.stop
+
+  stops all bisections
+
+$HOME/testing.git/$branch.stop
+
+  stop regular tests and bisections of $branch
+
+$HOME/branches/for-$branch.git/stop
+
+  stops regular tests $branch
+
+$HOME/bisects/for-$branch.git/stop
+
+  stops bisections of $branch
+
+$HOME/testing.git/$xenbranch.stop
+
+  stops everything using $xenbranch
-- 
2.1.4




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

[Xen-devel] [PATCH v3 2/3] xen/arm: Add new driver for R-Car Gen2 UART

[Oleksandr Tyshchenko]

Signed-off-by: Oleksandr Tyshchenko 
Signed-off-by: Iurii Konovalenko 
CC: Julien Grall 
---
 config/arm32.mk   |   1 +
 xen/drivers/char/Makefile |   1 +
 xen/drivers/char/rcar2-uart.c | 366 ++
 3 files changed, 368 insertions(+)
 create mode 100644 xen/drivers/char/rcar2-uart.c

diff --git a/config/arm32.mk b/config/arm32.mk
index 4f83a63..6ee5173 100644
--- a/config/arm32.mk
+++ b/config/arm32.mk
@@ -12,6 +12,7 @@ CFLAGS += -marm
 HAS_PL011 := y
 HAS_EXYNOS4210 := y
 HAS_OMAP := y
+HAS_RCAR2 := y
 HAS_NS16550 := y
 
 # Use only if calling $(LD) directly.
diff --git a/xen/drivers/char/Makefile b/xen/drivers/char/Makefile
index 911b788..64428b7 100644
--- a/xen/drivers/char/Makefile
+++ b/xen/drivers/char/Makefile
@@ -3,6 +3,7 @@ obj-$(HAS_NS16550) += ns16550.o
 obj-$(HAS_PL011) += pl011.o
 obj-$(HAS_EXYNOS4210) += exynos4210-uart.o
 obj-$(HAS_OMAP) += omap-uart.o
+obj-$(HAS_RCAR2) += rcar2-uart.o
 obj-$(HAS_EHCI) += ehci-dbgp.o
 obj-$(CONFIG_ARM) += dt-uart.o
 obj-y += serial.o
diff --git a/xen/drivers/char/rcar2-uart.c b/xen/drivers/char/rcar2-uart.c
new file mode 100644
index 000..7ace6ad
--- /dev/null
+++ b/xen/drivers/char/rcar2-uart.c
@@ -0,0 +1,366 @@
+/*
+ * xen/drivers/char/rcar2-uart.c
+ *
+ * Driver for R-Car Gen2 UART.
+ *
+ * Oleksandr Tyshchenko 
+ * Copyright (C) 2014, Globallogic.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define PARITY_NONE0
+#define PARITY_EVEN1
+#define PARITY_ODD 2
+
+#define rcar2_readb(uart, off)  readb((uart)->regs + (off))
+#define rcar2_writeb(uart, off, val)writeb((val), (uart)->regs + (off))
+
+#define rcar2_readw(uart, off)  readw((uart)->regs + (off))
+#define rcar2_writew(uart, off, val)writew((val), (uart)->regs + (off))
+
+static struct rcar2_uart {
+unsigned int baud, clock_hz, data_bits, parity, stop_bits;
+unsigned int irq;
+char __iomem *regs;
+struct irqaction irqaction;
+struct vuart_info vuart;
+} rcar2_com = {0};
+
+static void rcar2_uart_interrupt(int irq, void *data, struct cpu_user_regs 
*regs)
+{
+struct serial_port *port = data;
+struct rcar2_uart *uart = port->uart;
+uint16_t status, ctrl;
+
+ctrl = rcar2_readw(uart, SCIF_SCSCR);
+status = rcar2_readw(uart, SCIF_SCFSR) & ~SCFSR_TEND;
+/* Ignore next flag if TX Interrupt is disabled */
+if ( !(ctrl & SCSCR_TIE) )
+status &= ~SCFSR_TDFE;
+
+while ( status != 0 )
+{
+/* TX Interrupt */
+if ( status & SCFSR_TDFE )
+serial_tx_interrupt(port, regs);
+
+/* RX Interrupt */
+if ( status & (SCFSR_RDF | SCFSR_DR) )
+serial_rx_interrupt(port, regs);
+
+/* Error Interrupt */
+if ( status & SCIF_ERRORS )
+rcar2_writew(uart, SCIF_SCFSR, ~SCIF_ERRORS);
+if ( rcar2_readw(uart, SCIF_SCLSR) & SCLSR_ORER )
+rcar2_writew(uart, SCIF_SCLSR, 0);
+
+ctrl = rcar2_readw(uart, SCIF_SCSCR);
+status = rcar2_readw(uart, SCIF_SCFSR) & ~SCFSR_TEND;
+/* Ignore next flag if TX Interrupt is disabled */
+if ( !(ctrl & SCSCR_TIE) )
+status &= ~SCFSR_TDFE;
+}
+}
+
+static void __init rcar2_uart_init_preirq(struct serial_port *port)
+{
+struct rcar2_uart *uart = port->uart;
+unsigned int divisor;
+uint16_t val;
+
+/*
+ * Wait until last bit has been transmitted. This is needed for a smooth
+ * transition when we come from early printk
+ */
+while ( !(rcar2_readw(uart, SCIF_SCFSR) & SCFSR_TEND) );
+
+/* Disable TX/RX parts and all interrupts */
+rcar2_writew(uart, SCIF_SCSCR, 0);
+
+/* Reset TX/RX FIFOs */
+rcar2_writew(uart, SCIF_SCFCR, SCFCR_RFRST | SCFCR_TFRST);
+
+/* Clear all errors and flags */
+rcar2_readw(uart, SCIF_SCFSR);
+rcar2_writew(uart, SCIF_SCFSR, 0);
+rcar2_readw(uart, SCIF_SCLSR);
+rcar2_writew(uart, SCIF_SCLSR, 0);
+
+/* Select Baud rate generator output as a clock source */
+rcar2_writew(uart, SCIF_SCSCR, SCSCR_CKE10);
+
+/* Setup protocol format and Baud rate, select Asynchronous mode */
+val = 0;
+ASSERT( uart->data_bits >= 7 && uart->data_bits <= 8 );
+if ( uart->data_bits == 7 )
+val |= SCSMR_CHR;
+else
+val &= ~SCSMR_CHR;
+
+ASSERT( uart->stop_bits >= 1 && uart->stop_bits <= 2 );
+if ( uart->st

[Xen-devel] [PATCH v3 3/3] xen/arm: Introduce support for Renesas R-Car Gen2 platform

[Oleksandr Tyshchenko]

From: Iurii Konovalenko 

Signed-off-by: Iurii Konovalenko 
Reviewed-by: Julien Grall 
---
 xen/arch/arm/platforms/Makefile   |  1 +
 xen/arch/arm/platforms/shmobile.c | 71 +++
 2 files changed, 72 insertions(+)
 create mode 100644 xen/arch/arm/platforms/shmobile.c

diff --git a/xen/arch/arm/platforms/Makefile b/xen/arch/arm/platforms/Makefile
index 8f47c16..29e931a 100644
--- a/xen/arch/arm/platforms/Makefile
+++ b/xen/arch/arm/platforms/Makefile
@@ -4,5 +4,6 @@ obj-$(CONFIG_ARM_32) += exynos5.o
 obj-$(CONFIG_ARM_32) += midway.o
 obj-$(CONFIG_ARM_32) += omap5.o
 obj-$(CONFIG_ARM_32) += sunxi.o
+obj-$(CONFIG_ARM_32) += shmobile.o
 obj-$(CONFIG_ARM_64) += seattle.o
 obj-$(CONFIG_ARM_64) += xgene-storm.o
diff --git a/xen/arch/arm/platforms/shmobile.c 
b/xen/arch/arm/platforms/shmobile.c
new file mode 100644
index 000..c462b0e
--- /dev/null
+++ b/xen/arch/arm/platforms/shmobile.c
@@ -0,0 +1,71 @@
+/*
+ * xen/arch/arm/platforms/shmobile.c
+ *
+ * Renesas R-Car Gen2 specific settings
+ *
+ * Iurii Konovalenko 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#define SHMOBILE_RAM_ADDR 0xE63C
+#define SHMOBILE_RAM_SIZE 0x1000
+#define SHMOBILE_SMP_START_OFFSET 0xFFC
+
+static int __init shmobile_smp_init(void)
+{
+void __iomem *pram;
+
+/* map ICRAM */
+pram = ioremap_nocache(SHMOBILE_RAM_ADDR, SHMOBILE_RAM_SIZE);
+if( !pram )
+{
+dprintk( XENLOG_ERR, "Unable to map Shmobile ICRAM\n");
+return -ENOMEM;
+}
+
+/* setup reset vectors */
+writel(__pa(init_secondary), pram + SHMOBILE_SMP_START_OFFSET);
+iounmap(pram);
+
+sev();
+
+return 0;
+}
+
+static const char const *shmobile_dt_compat[] __initdata =
+{
+"renesas,lager",
+NULL
+};
+
+PLATFORM_START(shmobile, "Renesas R-Car Gen2")
+.compatible = shmobile_dt_compat,
+.cpu_up = cpu_up_send_sgi,
+.smp_init = shmobile_smp_init,
+
+.dom0_gnttab_start = 0xc000,
+.dom0_gnttab_size = 0x2,
+PLATFORM_END
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.9.1


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

Re: [Xen-devel] [PATCH v4 3/3] xen: prevent access to HPET from Dom0

[Jan Beulich]

>>> On 23.01.15 at 13:10,  wrote:
> Prevent Dom0 from accessing HPET MMIO region by adding the HPET mfn to the
> list of forbiden memory regions (if ACPI_HPET_PAGE_PROTECT4 or
> ACPI_HPET_PAGE_PROTECT64 flag is set) or to the list of read-only regions.
> 
> Also provide an option that prevents adding the HPET to the read-only memory
> regions called ro-hpet, in case there are systems that put other stuff in
> the HPET page.
> 
> Signed-off-by: Roger Pau Monné 

I had to fiddle with this a little before committing - please double
check.

Jan

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

Re: [Xen-devel] Release Manager for Xen 4.6

[Stefano Stabellini]

On Fri, 23 Jan 2015, Konrad Rzeszutek Wilk wrote:
> On Thu, Jan 22, 2015 at 03:12:08PM -0500, Konrad Rzeszutek Wilk wrote:
> > Hey,
> > 
> > I will becoming more involved in OpenStack to the point that
> > I cannot see myself wearing the Release Manager hat as well.
> > 
> > As such I would like to hand the jacket off to the next 
> > victi^M^M^Mvolunteer.
> 
> And I nominate Wei Liu (if he is up for it of course).

Nomination seconded

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

Re: [Xen-devel] [PATCH v3 0/2] x86/arm64: add xenconfig

[Stefano Stabellini]

On Fri, 23 Jan 2015, Luis R. Rodriguez wrote:
> On Wed, Jan 14, 2015 at 11:33:45AM -0800, Luis R. Rodriguez wrote:
> > From: "Luis R. Rodriguez" 
> > 
> > This v3 addresses Stefano's feedback from the v2 series, namely
> > moving PCI stuff to x86 as its all x86 specific and also just
> > removing the CONFIG_TCG_XEN=m from the general config. To be
> > clear the changes from the v2 series are below.
> > 
> > Luis R. Rodriguez (2):
> >   x86, platform, xen, kconfig: clarify kvmconfig is for kvm
> >   x86, arm, platform, xen, kconfig: add xen defconfig helper
> > 
> >  arch/x86/configs/xen.config | 10 ++
> >  kernel/configs/xen.config   | 26 ++
> >  scripts/kconfig/Makefile|  7 ++-
> >  3 files changed, 42 insertions(+), 1 deletion(-)
> >  create mode 100644 arch/x86/configs/xen.config
> >  create mode 100644 kernel/configs/xen.config
> 
> Who could these changes go through?

I would be OK with taking it in the Xen tree, but I would feel more
comfortable doing that if you had an ack from Yann Morin (CC'ed).

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

Re: [Xen-devel] [PATCH] README.dev: Document the usage of stop files

[Ian Jackson]

Ian Campbell writes ("[PATCH] README.dev: Document the usage of stop files"):
...
>  NOTE: $revision must be a revision *not* a tag.
> +
> +Temporarily stopping a branch or the entire system
> +==
> +
> +osstest can be paused by dropping a stop file into either the central
> +$HOME/testing.git or ~/branches/for-$branch.git etc.
> +
> +stop -- stops everything
> +daily.stop   -- stops all regular daily tests
> +bisects.stop -- stops all bisections
> +$branch.stop -- stops $branch
> +$xenbranch.stop  -- stops everything using $xenbranch
> +daily.stop   -- stops all regular daily tests

`daily.stop' is mentioned twice here.

You should probably mention that dropping `stop' into for-$branch.git
doesn't stop "everything" but only that branch.

Ian.

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

Re: [Xen-devel] Release Manager for Xen 4.6

[Konrad Rzeszutek Wilk]

On Thu, Jan 22, 2015 at 03:12:08PM -0500, Konrad Rzeszutek Wilk wrote:
> Hey,
> 
> I will becoming more involved in OpenStack to the point that
> I cannot see myself wearing the Release Manager hat as well.
> 
> As such I would like to hand the jacket off to the next victi^M^M^Mvolunteer.

And I nominate Wei Liu (if he is up for it of course).

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

[Xen-devel] [PATCH v1 19/21] Ovfm/Xen: add a Vendor Hardware device path GUID for the XenBus root

[Ard Biesheuvel]

On non-PCI Xen guests (such as ARM), the XenBus root is not a PCI
device but an abstract 'platform' device. Add a dedicated Vendor
Hardware device path GUID to identify this node.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 OvmfPkg/Include/Guid/XenBusRootDevice.h | 24 
 OvmfPkg/OvmfPkg.dec |  1 +
 2 files changed, 25 insertions(+)
 create mode 100644 OvmfPkg/Include/Guid/XenBusRootDevice.h

diff --git a/OvmfPkg/Include/Guid/XenBusRootDevice.h 
b/OvmfPkg/Include/Guid/XenBusRootDevice.h
new file mode 100644
index ..2b6e71018052
--- /dev/null
+++ b/OvmfPkg/Include/Guid/XenBusRootDevice.h
@@ -0,0 +1,24 @@
+/** @file
+  GUID to be used to identify the XenBus root node on non-PCI Xen guests
+
+  Copyright (C) 2015, Linaro Ltd.
+
+  This program and the accompanying materials are licensed and made available
+  under the terms and conditions of the BSD License that accompanies this
+  distribution. The full text of the license may be found at
+  http://opensource.org/licenses/bsd-license.php.
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, WITHOUT
+  WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#ifndef __XENBUS_ROOT_DEVICE_H__
+#define __XENBUS_ROOT_DEVICE_H__
+
+#define XENBUS_ROOT_DEVICE_GUID \
+{0xa732241f, 0x383d, 0x4d9c, {0x8a, 0xe1, 0x8e, 0x09, 0x83, 0x75, 0x89, 0xd7}}
+
+extern EFI_GUID gXenBusRootDeviceGuid;
+
+#endif
diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index 3711fa922311..d61600225919 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -53,6 +53,7 @@
   gEfiXenInfoGuid = {0xd3b46f3b, 0xd441, 0x1244, {0x9a, 0x12, 
0x0, 0x12, 0x27, 0x3f, 0xc1, 0x4d}}
   gOvmfPlatformConfigGuid = {0x7235c51c, 0x0c80, 0x4cab, {0x87, 0xac, 
0x3b, 0x08, 0x4a, 0x63, 0x04, 0xb1}}
   gVirtioMmioTransportGuid= {0x837dca9e, 0xe874, 0x4d82, {0xb2, 0x9a, 
0x23, 0xfe, 0x0e, 0x23, 0xd1, 0xe2}}
+  gXenBusRootDeviceGuid   = {0xa732241f, 0x383d, 0x4d9c, {0x8a, 0xe1, 
0x8e, 0x09, 0x83, 0x75, 0x89, 0xd7}}
 
 [Protocols]
   gVirtioDeviceProtocolGuid   = {0xfa920010, 0x6785, 0x4941, {0xb6, 0xec, 
0x49, 0x8c, 0x57, 0x9f, 0x16, 0x0a}}
-- 
1.8.3.2


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

Re: [Xen-devel] dom0 pvops and rearranging memory layout

[Juergen Gross]

On 01/23/2015 04:09 PM, Konrad Rzeszutek Wilk wrote:

On Fri, Jan 23, 2015 at 11:32:20AM +0100, Juergen Gross wrote:

Hi,

while testing new patches to support dom0 with more than 512 GB I
stumbled over an issue which - I think - is present in pvops for
some time now.

On boot the kernel rearranges the memory layout to match the host
E820 map. This is done to be able to access all I/O areas with
identity mapped pfns (pfn == mfn). So basically some memory pages
change their pfns while the mfns stay the same.

There is no check done whether the moved memory areas are actually
in use (e.g. via memblock_is_reserved()). This can lead to cases
where memory in use is put to an area which is made available for
new memory allocations soon afterwards. Memory in question could
be the initrd, the p2m map presented to dom0 by the hypervisor, or
(hopefully in theory only) even the kernel itself or it's initial
page tables built by the hypervisor.

In my test I had a p2m map of nearly 2GB size and the area between


Oh my. That is huge. Could you compress it? This would require of course
a new type of P2M - where would mark which MFNs are contingous.

And then during booting you could read over and find these special
ones and when creating the new P2M do the right uncompression?


I don't think that's the correct solution. It would require a new
hypervisor as well and we still wouldn't have a guarantee it will
work.

That's "only" for 1TB of memory. I think we want to support much
more.

And even if the p2m is okay, a huge initrd will still blow us up.


Juergen




2GB and 4GB had no RAM. So parts of the p2m map and the complete
initrd where subject to be remapped which led to an early PANIC.

I'll try to add some special handling for the initrd and the p2m
map. In case someone has a better idea: please tell me.


Juergen





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

[Xen-devel] [PATCH] README.dev: Document the usage of stop files

[Ian Campbell]

Signed-off-by: Ian Campbell 
---
 README.dev | 13 +
 1 file changed, 13 insertions(+)

diff --git a/README.dev b/README.dev
index 1257649..7ef4f89 100644
--- a/README.dev
+++ b/README.dev
@@ -132,3 +132,16 @@ $ cd ~/branches/for-$branch.git
 $ OSSTEST_CONFIG=production-config ./ap-push $branch $revision
 
 NOTE: $revision must be a revision *not* a tag.
+
+Temporarily stopping a branch or the entire system
+==
+
+osstest can be paused by dropping a stop file into either the central
+$HOME/testing.git or ~/branches/for-$branch.git etc.
+
+stop   -- stops everything
+daily.stop -- stops all regular daily tests
+bisects.stop   -- stops all bisections
+$branch.stop   -- stops $branch
+$xenbranch.stop-- stops everything using $xenbranch
+daily.stop -- stops all regular daily tests
-- 
2.1.4


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

Re: [Xen-devel] QEMU 2.2.0 in Xen 4.6

[Stefano Stabellini]

On Fri, 23 Jan 2015, Ian Campbell wrote:
> On Fri, 2015-01-23 at 14:42 +, Stefano Stabellini wrote:
> 
> > HVM guest -(PV)--> QEMU in Dom0 for guest
> > |
> > --(emulation)--> QEMU Stubdom-(syscall)->Linux Stubdom---(PV)--> QEMU 
> > Dom0 for stubdom
> 
> Here, and throughout what you said I think, "QEMU in Dom0 for guest"
> could equally well be e.g. "blkback in driver domain for guest" likewise
> the "... for stubdom" too.
>
> i.e. the PV backend for the stubdom or the guest doesn't necessarily
> need to be QEMU and doesn't necessarily need to be in dom0.
 
Indeed


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

Re: [Xen-devel] dom0 pvops and rearranging memory layout

[Konrad Rzeszutek Wilk]

On Fri, Jan 23, 2015 at 11:32:20AM +0100, Juergen Gross wrote:
> Hi,
> 
> while testing new patches to support dom0 with more than 512 GB I
> stumbled over an issue which - I think - is present in pvops for
> some time now.
> 
> On boot the kernel rearranges the memory layout to match the host
> E820 map. This is done to be able to access all I/O areas with
> identity mapped pfns (pfn == mfn). So basically some memory pages
> change their pfns while the mfns stay the same.
> 
> There is no check done whether the moved memory areas are actually
> in use (e.g. via memblock_is_reserved()). This can lead to cases
> where memory in use is put to an area which is made available for
> new memory allocations soon afterwards. Memory in question could
> be the initrd, the p2m map presented to dom0 by the hypervisor, or
> (hopefully in theory only) even the kernel itself or it's initial
> page tables built by the hypervisor.
> 
> In my test I had a p2m map of nearly 2GB size and the area between

Oh my. That is huge. Could you compress it? This would require of course
a new type of P2M - where would mark which MFNs are contingous.

And then during booting you could read over and find these special
ones and when creating the new P2M do the right uncompression?

> 2GB and 4GB had no RAM. So parts of the p2m map and the complete
> initrd where subject to be remapped which led to an early PANIC.
> 
> I'll try to add some special handling for the initrd and the p2m
> map. In case someone has a better idea: please tell me.
> 
> 
> Juergen

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

[Xen-devel] [PATCH v1 13/21] Ovmf/Xen: move arch specific hypercall implementation to XenHypercallLib

[Ard Biesheuvel]

For future ARM/AArch64 support in the XenBus code, move the implementation
of hypercall invocation to a dedicated library. The use of a library rather
than just an arch specific source in XenBusDxe.inf allows us to move the
constructor dependency on the gXenInfoGuid HOB to the library implementation.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 OvmfPkg/Include/Library/XenHypercallLib.h  |  78 ++
 .../XenHypercallLib}/Ia32/hypercall.nasm   |   6 +-
 .../XenHypercallLib}/X64/hypercall.nasm|   6 +-
 .../XenHypercallLib/XenHypercallLibCommon.c|  63 +++
 .../Library/XenHypercallLib/XenHypercallLibIntel.c |  77 ++
 .../XenHypercallLib/XenHypercallLibIntel.inf   |  52 +
 OvmfPkg/OvmfPkg.dec|   4 +
 OvmfPkg/OvmfPkgIa32.dsc|   1 +
 OvmfPkg/OvmfPkgIa32X64.dsc |   1 +
 OvmfPkg/OvmfPkgX64.dsc |   1 +
 OvmfPkg/XenBusDxe/EventChannel.c   |  14 +--
 OvmfPkg/XenBusDxe/GrantTable.c |   6 +-
 OvmfPkg/XenBusDxe/XenBusDxe.c  |  51 +++--
 OvmfPkg/XenBusDxe/XenBusDxe.h  |   1 -
 OvmfPkg/XenBusDxe/XenBusDxe.inf|  11 +-
 OvmfPkg/XenBusDxe/XenHypercall.c   | 118 -
 OvmfPkg/XenBusDxe/XenHypercall.h   | 113 
 OvmfPkg/XenBusDxe/XenStore.c   |   6 +-
 18 files changed, 338 insertions(+), 271 deletions(-)
 create mode 100644 OvmfPkg/Include/Library/XenHypercallLib.h
 rename OvmfPkg/{XenBusDxe => Library/XenHypercallLib}/Ia32/hypercall.nasm (81%)
 rename OvmfPkg/{XenBusDxe => Library/XenHypercallLib}/X64/hypercall.nasm (78%)
 create mode 100644 OvmfPkg/Library/XenHypercallLib/XenHypercallLibCommon.c
 create mode 100644 OvmfPkg/Library/XenHypercallLib/XenHypercallLibIntel.c
 create mode 100644 OvmfPkg/Library/XenHypercallLib/XenHypercallLibIntel.inf
 delete mode 100644 OvmfPkg/XenBusDxe/XenHypercall.c
 delete mode 100644 OvmfPkg/XenBusDxe/XenHypercall.h

diff --git a/OvmfPkg/Include/Library/XenHypercallLib.h 
b/OvmfPkg/Include/Library/XenHypercallLib.h
new file mode 100644
index ..6c94cbf7f2e6
--- /dev/null
+++ b/OvmfPkg/Include/Library/XenHypercallLib.h
@@ -0,0 +1,78 @@
+/** @file
+  Xen Hypercall Library definition
+
+Copyright (c) 2014, Linaro Ltd. All rights reserved.
+This program and the accompanying materials are licensed and made available 
under
+the terms and conditions of the BSD License that accompanies this distribution.
+The full text of the license may be found at
+http://opensource.org/licenses/bsd-license.php.
+
+THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#ifndef __XEN_HYPERCALL_LIB_H_
+#define __XEN_HYPERCALL_LIB_H_
+
+/**
+  Return the value of the HVM parameter Index.
+
+  @param Index  The parameter to get, e.g. HVM_PARAM_STORE_EVTCHN.
+
+  @return   The value of the asked parameter or 0 in case of error.
+**/
+UINT64
+XenHypercallHvmGetParam (
+  UINT32 Index
+  );
+
+/**
+  Hypercall to do different operation on the memory.
+
+  @param Operation  The operation number, e.g. XENMEM_add_to_physmap.
+  @param Arguments  The arguments associated to the operation.
+
+  @return  Return the return value from the hypercall, 0 in case of success
+   otherwise, an error code.
+**/
+INTN
+XenHypercallMemoryOp (
+  IN UINTN Operation,
+  IN OUT VOID *Arguments
+  );
+
+/**
+  Do an operation on the event channels.
+
+  @param Operation  The operation number, e.g. EVTCHNOP_send.
+  @param Arguments  The argument associated to the operation.
+
+  @return  Return the return value from the hypercall, 0 in case of success
+   otherwise, an error code.
+**/
+INTN
+XenHypercallEventChannelOp (
+  IN INTN Operation,
+  IN OUT VOID *Arguments
+  );
+
+/**
+  This function will put the two arguments in the right place (registers) and
+  invoke the hypercall identified by HypercallID.
+
+  @param HypercallIDThe symbolic ID of the hypercall to be invoked
+  @param Arg1   First argument.
+  @param Arg2   Second argument.
+
+  @return   Return 0 if success otherwise it return an errno.
+**/
+INTN
+EFIAPI
+XenHypercall2 (
+  IN INTN HypercallID,
+  IN OUT INTN Arg1,
+  IN OUT INTN Arg2
+  );
+
+#endif
diff --git a/OvmfPkg/XenBusDxe/Ia32/hypercall.nasm 
b/OvmfPkg/Library/XenHypercallLib/Ia32/hypercall.nasm
similarity index 81%
rename from OvmfPkg/XenBusDxe/Ia32/hypercall.nasm
rename to OvmfPkg/Library/XenHypercallLib/Ia32/hypercall.nasm
index 8547c30b81ee..e0fa71bb5ba8 100644
--- a/OvmfPkg/XenBusDxe/Ia32/hypercall.nasm
+++ b/OvmfPkg/Library/XenHypercallLib/Ia32/hypercall.nasm
@@ -2,13 +2,13 @@ SECTION .text
 
 ; INTN
 ; EFIAPI
-; XenHypercall2 (
+

Re: [Xen-devel] [PATCH v3 2/3] xen/pvh: check permissions when adding MMIO regions

[Konrad Rzeszutek Wilk]

On Fri, Jan 23, 2015 at 11:21:11AM +, Jan Beulich wrote:
> >>> On 22.01.15 at 21:28,  wrote:
> > On Thu, Jan 22, 2015 at 04:19:22PM +0100, Roger Pau Monne wrote:
> >> Check that MMIO regions added to PVH Dom0 are allowed. Previously a PVH 
> >> Dom0
> >> would have access to the full MMIO range.
> > 
> > How do we do this for normal PV dom0? Do we enforce the same
> > restriction?
> 
> We do, at the MMU level at least. Thing is (see an earlier
> reply, maybe on Elena's thread) that we may still be too lax.

Looking at vtd_set_hwdom_mapping looks to be having quite simplified
mechanism for PV. This is of course for those weird devices that
do DMA operations behind the OS'es back.

If we go that route we would probablly need logic in there to change
too - otherwise we have .. Ah, this is where Tim's idea of having
a guest just having an flag of 'I_need_IOMMU' would be so nice and
having only one code-path that could be used for both PV and PVH.


> 
> Jan
> 

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