[Xen-devel] [qemu-upstream-4.3-testing test] 95217: trouble: blocked/broken

2016-06-02 Thread osstest service owner
flight 95217 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95217/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   3 host-install(3) broken REGR. vs. 80927
 build-i386-pvops  3 host-install(3) broken REGR. vs. 80927
 build-i3863 host-install(3) broken REGR. vs. 80927
 build-amd64-pvops 3 host-install(3) broken REGR. vs. 80927

Tests which did not succeed, but are not blocking:
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-pv1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-pv   1 build-check(1)   blocked  n/a

version targeted for testing:
 qemuuc97c20f71240a538a19cb6b0e598bc1bbd5168f1
baseline version:
 qemuu10c1b763c26feb645627a1639e722515f3e1e876

Last test of basis80927  2016-02-06 13:30:02 Z  117 days
Testing same since93977  2016-05-10 11:09:16 Z   23 days  101 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Stefano Stabellini 

jobs:
 build-amd64  broken  
 build-i386   broken  
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-xl  blocked 
 test-amd64-i386-xl   blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd   blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked 
 test-amd64-i386-freebsd10-amd64  blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64 blocked 
 test-amd64-i386-xl-qemuu-win7-amd64  blocked 
 test-amd64-amd64-xl-credit2  blocked 
 test-amd64-i386-freebsd10-i386   blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel blocked 
 test-amd64-amd64-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-xl-multivcpublocked 
 

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

2016-06-02 Thread osstest service owner
flight 95203 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95203/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 build-amd64-rumpuserxen   6 xen-buildfail   like 95129
 build-i386-rumpuserxen6 xen-buildfail   like 95129
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 95129
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 95129
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 95129
 test-amd64-amd64-xl-rtds  9 debian-install   fail   like 95129
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 95129

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-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  181677977fc35ddb848ae4d440fbb72e8afc8a1e
baseline version:
 xen  bbfd2d6ccb31a3aeea49c8f9c7884792ddc26e3b

Last test of basis95129  2016-06-01 11:11:52 Z1 days
Failing since 95174  2016-06-01 21:43:56 Z1 days2 attempts
Testing same since95203  2016-06-02 15:55:18 Z0 days1 attempts


People who touched revisions under test:
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Stefano Stabellini 
  Suravee Suthikulpanit 
  Vitaly Kuznetsov 
  Wei Chen 
  Wei Liu 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt   

Re: [Xen-devel] [PATCH v2 3/4] VMX: Assign the right value to 'NDST' field in a concern case

2016-06-02 Thread Wu, Feng


> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, May 31, 2016 7:58 PM
> To: Wu, Feng 
> Cc: andrew.coop...@citrix.com; dario.faggi...@citrix.com;
> george.dun...@eu.citrix.com; Tian, Kevin ; xen-
> de...@lists.xen.org; konrad.w...@oracle.com; k...@xen.org
> Subject: RE: [PATCH v2 3/4] VMX: Assign the right value to 'NDST' field in a
> concern case
> 
> >>> On 31.05.16 at 12:27,  wrote:
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: Friday, May 27, 2016 10:00 PM
> >> >>> On 26.05.16 at 15:39,  wrote:
> >> > Normally, in vmx_cpu_block() 'NDST' filed should have the same
> >> > value with 'dest' or 'MASK_INSR(dest, PI_xAPIC_NDST_MASK)' depending
> >> > on whether x2apic is enabled. However, in the following scenario,
> >> > 'NDST' has different value:
> >> >
> >> > 'vcpu_block' hook gets assigned in vmx_pi_hooks_assign(), but all
> >> > other three PI hooks have not been assigned or not been excuted yet.
> >> > And during this interval, we are running in vmx_vcpu_block(), then
> >> > 'NDST' may have different value.
> >>
> >> How about simply assigning vcpu_block last? Or alternatively
> >> holding pi_blocking_list_lock around all four assignments? Or
> >> (maybe in addition to one of these) writing something sensible in
> >> vmx_pi_hooks_assign() before doing the hook assignments?
> >
> > The problem is vmx_vcpu_block() can still get called first, since
> > the other ones might not get called yet.
> 
> That refers to the first two questions, yet the third (unanswered
> one) was added by me because I anticipated that response. So
> what's wrong with that last option?

Do you mean " Or (maybe in addition to one of these) writing
something sensible in vmx_pi_hooks_assign() before doing the
hook assignments?"?

The problem is you cannot know whether vmx_vcpu_block() is
called before or after the other hooks. And I am wondering
why do you think the current solution is not good.

Thanks,
Feng

> 
> Jan


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


Re: [Xen-devel] [PATCH v2 1/4] VMX: Properly handle pi when all the assigned devices are removed

2016-06-02 Thread Wu, Feng


> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, May 31, 2016 7:52 PM
> To: Wu, Feng 
> Cc: andrew.coop...@citrix.com; dario.faggi...@citrix.com;
> george.dun...@eu.citrix.com; Tian, Kevin ; xen-
> de...@lists.xen.org; konrad.w...@oracle.com; k...@xen.org
> Subject: RE: [PATCH v2 1/4] VMX: Properly handle pi when all the assigned
> devices are removed
> 
> >>> On 31.05.16 at 12:22,  wrote:
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: Friday, May 27, 2016 9:43 PM
> >> >>> On 26.05.16 at 15:39,  wrote:
> >> > --- a/xen/arch/x86/hvm/vmx/vmx.c
> >> > +++ b/xen/arch/x86/hvm/vmx/vmx.c
> >> > @@ -113,7 +113,19 @@ static void vmx_vcpu_block(struct vcpu *v)
> >> >  _cpu(vmx_pi_blocking, v->processor).lock;
> >> >  struct pi_desc *pi_desc = >arch.hvm_vmx.pi_desc;
> >> >
> >> > -spin_lock_irqsave(pi_blocking_list_lock, flags);
> >> > +spin_lock_irqsave(>arch.hvm_vmx.pi_hotplug_lock, flags);
> >> > +if ( unlikely(v->arch.hvm_vmx.pi_blocking_cleaned_up) )
> >> > +{
> >> > +/*
> >> > + * The vcpu is to be destroyed and it has already been removed
> >> > + * from the per-CPU list if it is blocking, we shouldn't add
> >> > + * new vCPU to the list.
> >> > + */
> >>
> >> This comment appears to be stale wrt the implementation further
> >> down. But see there for whether it's the comment or the code
> >> that need to change.
> >>
> >> > +spin_unlock_irqrestore(>arch.hvm_vmx.pi_hotplug_lock, flags);
> >> > +return;
> >> > +}
> >> > +
> >> > +spin_lock(pi_blocking_list_lock);
> >>
> >> There doesn't appear to be an active problem with this, but
> >> taking a global lock inside a per-vCPU one feels bad. Both here
> >> and in vmx_pi_blocking_cleanup() I can't see why the global
> >> lock alone won't do - you acquire it anyway.
> >
> > The purpose of ' v->arch.hvm_vmx.pi_hotplug_lock ' is to make
> > sure things go right when vmx_pi_blocking_cleanup() and
> > vmx_vcpu_block() are running concurrently. However, the lock
> > 'pi_blocking_list_lock' in vmx_pi_blocking_cleanup() refers to
> > ' v->arch.hvm_vmx.pi_blocking.lock ' while 'pi_blocking_list_lock'
> > in vmx_vcpu_block() is '_cpu(vmx_pi_blocking, v->processor).lock'.
> > These two can be different, please consider the following scenario:
> >
> > vmx_pi_blocking_cleanup() gets called when the vcpu is in blocking
> > state and 'v->arch.hvm_vmx.pi_blocking.lock' points to the per-cpu
> > lock of pCPU0, and when acquiring the lock in this function, another
> > one wins, (such as vmx_pi_do_resume() or pi_wakeup_interrupt()),
> > so we are spinning in vmx_pi_blocking_cleanup(). After the vCPU
> > is woken up, it is running on pCPU1, then sometime later, the vCPU
> > is blocking again and in vmx_vcpu_block() and if the previous
> > vmx_pi_blocking_cleanup() still doesn't finish its job. Then we
> > acquire a different lock (it is pCPU1 this time)in vmx_vcpu_block()
> > compared to the one in vmx_pi_blocking_cleanup. This can break
> > things, since we might still put the vCPU to the per-cpu blocking list
> > after vCPU is destroyed or the last assigned device is detached.
> 
> Makes sense. Then the next question is whether you really need
> to hold both locks at the same time.

I think we need to hold both. The two spinlocks have different purpose:
'v->arch.hvm_vmx.pi_hotplug_lock' is to protect some race case while
device hotplug or the domain is being down, while the other one is
used to normally protect accesses to the blocking list.

> Please understand that I'd
> really prefer for this to have a simpler solution - the original code
> was already more complicated than one would really think it should
> be, and now it's getting worse. While I can't immediately suggest
> alternatives, it feels like the solution to the current problem may
> rather be simplification instead of making things even more
> complicated.

To be honest, comments like this make one frustrated. If you have
any other better solutions, we can discuss it here. However, just
saying the current solution is too complicated is not a good way
to speed up the process.

> 
> >> >  void vmx_pi_hooks_deassign(struct domain *d)
> >> >  {
> >> > +struct vcpu *v;
> >> > +
> >> >  if ( !iommu_intpost || !has_hvm_container_domain(d) )
> >> >  return;
> >> >
> >> > -ASSERT(d->arch.hvm_domain.vmx.vcpu_block);
> >> > -
> >> > -d->arch.hvm_domain.vmx.vcpu_block = NULL;
> >> > -d->arch.hvm_domain.vmx.pi_switch_from = NULL;
> >> > -d->arch.hvm_domain.vmx.pi_switch_to = NULL;
> >> > -d->arch.hvm_domain.vmx.pi_do_resume = NULL;
> >> > +for_each_vcpu ( d, v )
> >> > +vmx_pi_blocking_cleanup(v);
> >>
> >> If you keep the hooks in place, why is it relevant to do the cleanup
> >> here instead of just at domain death? As suggested before, if you
> 

Re: [Xen-devel] [PATCH for-4.7] x86/cpuid: Calculate a guests xfeature_mask from its featureset

2016-06-02 Thread Kang, Luwei
I have finsh test  this patch and it work well, thank Andrew and all.


-Original Message-
From: Andrew Cooper [mailto:andrew.coop...@citrix.com] 
Sent: Friday, June 3, 2016 12:48 AM
To: Xen-devel 
Cc: Andrew Cooper ; Jan Beulich ; 
Wei Liu ; Kang, Luwei ; Han, 
Huaitong 
Subject: [PATCH for-4.7] x86/cpuid: Calculate a guests xfeature_mask from its 
featureset

libxc current performs the xstate calculation for guests, and provides the 
information to Xen to be used when satisfying CPUID traps.  (There is further 
work planned to improve this arrangement, but the worst a buggy toolstack can 
do is make junk appear in the cpuid leaves for the guest.)

dom0 however has no policy constructed for it, and certain fields filter 
straight through from hardware.

Linux queries CPUID.7[0].{EAX/EDX} alone to choose a setting for %xcr0, which 
is action to take.  However, features such as MPX and PKRU are not supported 
for PV guests.  As a result, Linux, using leaked hardware information, fails to 
set %xcr0 on newer Skylake hardware with PKRU support, and crashes.

As an interim solution, dynamically calculate the correct xfeature_mask and 
xstate_size to report to the guest for CPUID.7[0] queries.  This ensures that 
domains don't see leaked hardware values, even when no cpuid policy is provided.

Similarly, CPUID.7[1]{ECX/EDX} represents the applicable settings for MSR_XSS.  
Xen doesn't support any XSS states in guests, unconditionally clear them for 
HVM guests.

Reported-by: Luwei Kang 
Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Wei Liu 
CC: Luwei Kang 
CC: Huaitong Han 
---
 xen/arch/x86/hvm/hvm.c   | 53 ++--
 xen/arch/x86/traps.c | 50 -
 xen/arch/x86/xstate.c|  2 +-
 xen/include/asm-x86/xstate.h | 32 +-
 4 files changed, 114 insertions(+), 23 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c index 
bb98051..72bbed5 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3362,7 +3362,7 @@ void hvm_cpuid(unsigned int input, unsigned int *eax, 
unsigned int *ebx,
 
 switch ( input )
 {
-unsigned int _ecx, _edx;
+unsigned int _ebx, _ecx, _edx;
 
 case 0x1:
 /* Fix up VLAPIC details. */
@@ -3443,6 +3443,51 @@ void hvm_cpuid(unsigned int input, unsigned int *eax, 
unsigned int *ebx,
 switch ( count )
 {
 case 0:
+{
+uint64_t xfeature_mask = XSTATE_FP_SSE;
+uint32_t xstate_size = XSTATE_AREA_MIN_SIZE;
+
+if ( _ecx & cpufeat_mask(X86_FEATURE_AVX) )
+{
+xfeature_mask |= XSTATE_YMM;
+xstate_size = MAX(xstate_size,
+  xstate_offsets[_XSTATE_YMM] +
+  xstate_sizes[_XSTATE_YMM]);
+}
+
+_ecx = 0;
+hvm_cpuid(7, NULL, &_ebx, &_ecx, NULL);
+
+if ( _ebx & cpufeat_mask(X86_FEATURE_MPX) )
+{
+xfeature_mask |= XSTATE_BNDREGS | XSTATE_BNDCSR;
+xstate_size = MAX(xstate_size,
+  xstate_offsets[_XSTATE_BNDCSR] +
+  xstate_sizes[_XSTATE_BNDCSR]);
+}
+
+if ( _ebx & cpufeat_mask(X86_FEATURE_PKU) )
+{
+xfeature_mask |= XSTATE_PKRU;
+xstate_size = MAX(xstate_size,
+  xstate_offsets[_XSTATE_PKRU] +
+  xstate_sizes[_XSTATE_PKRU]);
+}
+
+hvm_cpuid(0x8001, NULL, NULL, &_ecx, NULL);
+
+if ( _ecx & cpufeat_mask(X86_FEATURE_LWP) )
+{
+xfeature_mask |= XSTATE_LWP;
+xstate_size = MAX(xstate_size,
+  xstate_offsets[_XSTATE_LWP] +
+  xstate_sizes[_XSTATE_LWP]);
+}
+
+*eax = (uint32_t)xfeature_mask;
+*edx = (uint32_t)(xfeature_mask >> 32);
+*ecx = xstate_size;
+
 /*
  * Always read CPUID[0xD,0].EBX from hardware, rather than domain
  * policy.  It varies with enabled xstate, and the correct xcr0 is 
@@ -3450,6 +3495,8 @@ void hvm_cpuid(unsigned int input, unsigned int *eax, 
unsigned int *ebx,
  */
 cpuid_count(input, count, , ebx, , );
 break;
+}
+
 case 1:
 *eax &= hvm_featureset[FEATURESET_Da1];
 
@@ -3463,7 +3510,9 @@ void hvm_cpuid(unsigned int input, unsigned int *eax, 
unsigned int *ebx,
 

Re: [Xen-devel] [PATCH] VMX: relax incoming BNDCFGS check

2016-06-02 Thread Tian, Kevin
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, May 30, 2016 6:06 PM
> 
> Accepting zero here even when !cpu_has_mpx makes the restore side
> symmetric to the save logic (which avoids saving the value if zero),
> i.e. makes either side independent of the logic on the other side.
> 
> Signed-off-by: Jan Beulich 
> 

Acked-by: Kevin Tian 

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


Re: [Xen-devel] questions of vm save/restore on arm64

2016-06-02 Thread Chenxiao Zhao



On 6/2/2016 5:29 AM, Julien Grall wrote:

Hello,

On 01/06/16 01:28, Chenxiao Zhao wrote:



On 5/30/2016 4:40 AM, Stefano Stabellini wrote:

On Fri, 27 May 2016, Chenxiao Zhao wrote:

Hi,

My board is Hikey on which have octa-core of arm cortex-a53. I have
applied patches [1] to try vm save/restore on arm.
These patches originally do not working on arm64. I have made some
changes based on patch set [2].


Hello Chenxiao,

thanks for your interest in Xen on ARM save/restore.


Hi Stefano,

Thanks for your advice.

I found a possible reason that cause the restore failure is that xen
always failed on p2m_lookup for guest domain.


Who is calling p2m_lookup?


It call by handle_hvm_params(tools/libxc/xc_sr_restore_arm.c) while 
restoring HVM_PARAM_STORE_PFN.






I called dump_p2m_lookup in p2m_look() and get the output like below:

(XEN) dom1 IPA 0x39001000


Looking at the memory layout (see include/public/arch-arm.h) 0x39001000
is part of the magic region. It contains pages for the console,
xenstore, memaccess (see the list in tools/libxc/xc_dom_arm.c).


yes, I also noticed that.



0x39001000 is the base address of the xenstore page.


(XEN) P2M @ 000801e7ce80 mfn:0x79f3a
(XEN) Using concatenated root table 0
(XEN) 1ST[0x0] = 0x004079f3c77f
(XEN) 2ND[0x1c8] = 0x

My question is:

1. who is responsible for restoring p2m table, Xen or guest kernel?


AFAIK, the toolstack is restoring the most of the memory.


2. After restore, the vm always get zero memory space, but there is no


What do you mean by "zero memory space"?


I mean xl does not assign any memory to the restored VM.

NameID   Mem VCPUs  State 
Time(s)
Domain-0 0  1024 8 r- 
  76.3
guest2 0 1 r- 
   1.9






error reported on the restore progress. Does the memory requested by the
guest kernel or should be allocated early by hypervisor?


Bear in mind that the patch series you are working on is an RFC and the
ARM64 was not supported. There might be some issue in the save/restore
path.

For instance xc_clear_domain_page (tools/libxc/xc_sr_restore_arm.c) main
return an error if the memory is not mapped. But the caller does not
check the return value.

Regards,


I finally found out that the problem is that the toolstack did not get 
corret p2m_size while sending all pages on save(always be zero). After I 
fixed that, the guest could be restored but guest kernel caught 
handle_mm_fault().


where do you think I'm going to investigate, guest kernel hibernation 
restore or xen?


Best regards.





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


[Xen-devel] [qemu-upstream-4.3-testing test] 95210: trouble: blocked/broken

2016-06-02 Thread osstest service owner
flight 95210 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95210/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   3 host-install(3) broken REGR. vs. 80927
 build-i386-pvops  3 host-install(3) broken REGR. vs. 80927
 build-i3863 host-install(3) broken REGR. vs. 80927
 build-amd64-pvops 3 host-install(3) broken REGR. vs. 80927

Tests which did not succeed, but are not blocking:
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-pv1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-pv   1 build-check(1)   blocked  n/a

version targeted for testing:
 qemuuc97c20f71240a538a19cb6b0e598bc1bbd5168f1
baseline version:
 qemuu10c1b763c26feb645627a1639e722515f3e1e876

Last test of basis80927  2016-02-06 13:30:02 Z  117 days
Testing same since93977  2016-05-10 11:09:16 Z   23 days  100 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Stefano Stabellini 

jobs:
 build-amd64  broken  
 build-i386   broken  
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-xl  blocked 
 test-amd64-i386-xl   blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd   blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked 
 test-amd64-i386-freebsd10-amd64  blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64 blocked 
 test-amd64-i386-xl-qemuu-win7-amd64  blocked 
 test-amd64-amd64-xl-credit2  blocked 
 test-amd64-i386-freebsd10-i386   blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel blocked 
 test-amd64-amd64-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-xl-multivcpublocked 
 

[Xen-devel] [xen-unstable-smoke test] 95214: tolerable all pass - PUSHED

2016-06-02 Thread osstest service owner
flight 95214 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95214/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  e228585d122817f987806145b09de7914c42a5fe
baseline version:
 xen  91fbfc37f5421bb2c5b08902a4a0bb4d1f8dc6ba

Last test of basis95204  2016-06-02 16:02:12 Z0 days
Testing same since95214  2016-06-02 21:04:06 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 
  Konrad Rzeszutek Wilk 
  Wei Liu 

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



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=e228585d122817f987806145b09de7914c42a5fe
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
e228585d122817f987806145b09de7914c42a5fe
+ branch=xen-unstable-smoke
+ revision=e228585d122817f987806145b09de7914c42a5fe
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.6-testing
+ '[' xe228585d122817f987806145b09de7914c42a5fe = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/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.xen.org:/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 

[Xen-devel] [PATCH v5 4/9] monitor: Rename hvm/event to hvm/monitor

2016-06-02 Thread Tamas K Lengyel
Mechanical renaming to better describe that the code in hvm/event is part of
the monitor subsystem.

Signed-off-by: Tamas K Lengyel 
Acked-by: Kevin Tian 
Acked-by: Razvan Cojocaru 
Acked-by: Jan Beulich 
---
Cc: Andrew Cooper 
Cc: Jun Nakajima 
---
 xen/arch/x86/hvm/Makefile  |  2 +-
 xen/arch/x86/hvm/hvm.c | 12 +--
 xen/arch/x86/hvm/{event.c => monitor.c}| 17 ---
 xen/arch/x86/hvm/vmx/vmx.c | 13 +--
 xen/include/asm-x86/hvm/{event.h => monitor.h} | 30 +-
 5 files changed, 38 insertions(+), 36 deletions(-)
 rename xen/arch/x86/hvm/{event.c => monitor.c} (88%)
 rename xen/include/asm-x86/hvm/{event.h => monitor.h} (59%)

diff --git a/xen/arch/x86/hvm/Makefile b/xen/arch/x86/hvm/Makefile
index 8bc55a9..f750d13 100644
--- a/xen/arch/x86/hvm/Makefile
+++ b/xen/arch/x86/hvm/Makefile
@@ -3,7 +3,6 @@ subdir-y += vmx
 
 obj-y += asid.o
 obj-y += emulate.o
-obj-y += event.o
 obj-y += hpet.o
 obj-y += hvm.o
 obj-y += i8254.o
@@ -11,6 +10,7 @@ obj-y += intercept.o
 obj-y += io.o
 obj-y += ioreq.o
 obj-y += irq.o
+obj-y += monitor.o
 obj-y += mtrr.o
 obj-y += nestedhvm.o
 obj-y += pmtimer.o
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 7bf6a36..c4089be 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -60,7 +60,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
@@ -1961,7 +1961,7 @@ int hvm_handle_xsetbv(u32 index, u64 new_bv)
 {
 int rc;
 
-hvm_event_crX(XCR0, new_bv, current->arch.xcr0);
+hvm_monitor_crX(XCR0, new_bv, current->arch.xcr0);
 
 rc = handle_xsetbv(index, new_bv);
 if ( rc )
@@ -2197,7 +2197,7 @@ int hvm_set_cr0(unsigned long value, bool_t may_defer)
 {
 ASSERT(v->arch.vm_event);
 
-if ( hvm_event_crX(CR0, value, old_value) )
+if ( hvm_monitor_crX(CR0, value, old_value) )
 {
 /* The actual write will occur in hvm_do_resume(), if permitted. */
 v->arch.vm_event->write_data.do_write.cr0 = 1;
@@ -2299,7 +2299,7 @@ int hvm_set_cr3(unsigned long value, bool_t may_defer)
 {
 ASSERT(v->arch.vm_event);
 
-if ( hvm_event_crX(CR3, value, old) )
+if ( hvm_monitor_crX(CR3, value, old) )
 {
 /* The actual write will occur in hvm_do_resume(), if permitted. */
 v->arch.vm_event->write_data.do_write.cr3 = 1;
@@ -2379,7 +2379,7 @@ int hvm_set_cr4(unsigned long value, bool_t may_defer)
 {
 ASSERT(v->arch.vm_event);
 
-if ( hvm_event_crX(CR4, value, old_cr) )
+if ( hvm_monitor_crX(CR4, value, old_cr) )
 {
 /* The actual write will occur in hvm_do_resume(), if permitted. */
 v->arch.vm_event->write_data.do_write.cr4 = 1;
@@ -3722,7 +3722,7 @@ int hvm_msr_write_intercept(unsigned int msr, uint64_t 
msr_content,
 v->arch.vm_event->write_data.msr = msr;
 v->arch.vm_event->write_data.value = msr_content;
 
-hvm_event_msr(msr, msr_content);
+hvm_monitor_msr(msr, msr_content);
 return X86EMUL_OKAY;
 }
 
diff --git a/xen/arch/x86/hvm/event.c b/xen/arch/x86/hvm/monitor.c
similarity index 88%
rename from xen/arch/x86/hvm/event.c
rename to xen/arch/x86/hvm/monitor.c
index 5772c6b..764c3e8 100644
--- a/xen/arch/x86/hvm/event.c
+++ b/xen/arch/x86/hvm/monitor.c
@@ -1,5 +1,5 @@
 /*
- * arch/x86/hvm/event.c
+ * arch/x86/hvm/monitor.c
  *
  * Arch-specific hardware virtual machine event abstractions.
  *
@@ -7,6 +7,7 @@
  * Copyright (c) 2005, International Business Machines Corporation.
  * Copyright (c) 2008, Citrix Systems, Inc.
  * Copyright (c) 2016, Bitdefender S.R.L.
+ * Copyright (c) 2016, Tamas K Lengyel (ta...@tklengyel.com)
  *
  * This program is free software; you can redistribute it and/or modify it
  * under the terms and conditions of the GNU General Public License,
@@ -22,12 +23,12 @@
  */
 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
 
-bool_t hvm_event_cr(unsigned int index, unsigned long value, unsigned long old)
+bool_t hvm_monitor_cr(unsigned int index, unsigned long value, unsigned long 
old)
 {
 struct vcpu *curr = current;
 struct arch_domain *ad = >domain->arch;
@@ -54,7 +55,7 @@ bool_t hvm_event_cr(unsigned int index, unsigned long value, 
unsigned long old)
 return 0;
 }
 
-void hvm_event_msr(unsigned int msr, uint64_t value)
+void hvm_monitor_msr(unsigned int msr, uint64_t value)
 {
 struct vcpu *curr = current;
 struct arch_domain *ad = >domain->arch;
@@ -87,8 +88,8 @@ static inline unsigned long gfn_of_rip(unsigned long rip)
 return paging_gva_to_gfn(curr, sreg.base + rip, );
 }
 
-int hvm_event_breakpoint(unsigned long rip,
- enum hvm_event_breakpoint_type 

[Xen-devel] [PATCH v5 6/9] arm/vm_event: get/set registers

2016-06-02 Thread Tamas K Lengyel
Add support for getting/setting registers through vm_event on ARM.
The set of registers can be expanded in the future to include other registers
as well if required. The set is limited to the GPRs, PC, CPSR and TTBR0/1 in
this patch.

Signed-off-by: Tamas K Lengyel 
Acked-by: Razvan Cojocaru 
---
Cc: Stefano Stabellini 
Cc: Julien Grall 

v5: Use x29/x30 as names instead of the Xen internal names on 64-bit
Transmit all GPRs on 64-bit
v4: Use psr mode to determine whether to full 32-bit or 64-bit structs
---
 xen/arch/arm/Makefile  |   1 +
 xen/arch/arm/vm_event.c| 159 +
 xen/include/asm-arm/vm_event.h |  11 ---
 xen/include/asm-x86/vm_event.h |   4 --
 xen/include/public/vm_event.h  |  74 ++-
 xen/include/xen/vm_event.h |   3 +
 6 files changed, 234 insertions(+), 18 deletions(-)
 create mode 100644 xen/arch/arm/vm_event.c

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 344d3ad..7d2641c 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -42,6 +42,7 @@ obj-y += processor.o
 obj-y += smc.o
 obj-$(CONFIG_XSPLICE) += xsplice.o
 obj-y += monitor.o
+obj-y += vm_event.o
 
 #obj-bin-y += o
 
diff --git a/xen/arch/arm/vm_event.c b/xen/arch/arm/vm_event.c
new file mode 100644
index 000..6e92f8b
--- /dev/null
+++ b/xen/arch/arm/vm_event.c
@@ -0,0 +1,159 @@
+/*
+ * arch/arm/vm_event.c
+ *
+ * Architecture-specific vm_event handling routines
+ *
+ * Copyright (c) 2016 Tamas K Lengyel (ta...@tklengyel.com)
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this program; If not, see .
+ */
+
+#include 
+#include 
+
+void vm_event_fill_regs(vm_event_request_t *req)
+{
+const struct cpu_user_regs *regs = guest_cpu_user_regs();
+
+req->data.regs.arm.cpsr = regs->cpsr;
+req->data.regs.arm.ttbr0 = READ_SYSREG64(TTBR0_EL1);
+req->data.regs.arm.ttbr1 = READ_SYSREG64(TTBR1_EL1);
+
+if ( psr_mode_is_32bit(regs->cpsr) )
+{
+req->data.regs.arm.arch.arm32.r0 = regs->r0;
+req->data.regs.arm.arch.arm32.r1 = regs->r1;
+req->data.regs.arm.arch.arm32.r2 = regs->r2;
+req->data.regs.arm.arch.arm32.r3 = regs->r3;
+req->data.regs.arm.arch.arm32.r4 = regs->r4;
+req->data.regs.arm.arch.arm32.r5 = regs->r5;
+req->data.regs.arm.arch.arm32.r6 = regs->r6;
+req->data.regs.arm.arch.arm32.r7 = regs->r7;
+req->data.regs.arm.arch.arm32.r8 = regs->r8;
+req->data.regs.arm.arch.arm32.r9 = regs->r9;
+req->data.regs.arm.arch.arm32.r10 = regs->r10;
+req->data.regs.arm.arch.arm32.r11 = regs->fp;
+req->data.regs.arm.arch.arm32.r12 = regs->r12;
+req->data.regs.arm.arch.arm32.pc = regs->pc32;
+}
+#ifdef CONFIG_ARM_64
+else
+{
+req->data.regs.arm.arch.arm64.x0 = regs->x0;
+req->data.regs.arm.arch.arm64.x1 = regs->x1;
+req->data.regs.arm.arch.arm64.x2 = regs->x2;
+req->data.regs.arm.arch.arm64.x3 = regs->x3;
+req->data.regs.arm.arch.arm64.x4 = regs->x4;
+req->data.regs.arm.arch.arm64.x5 = regs->x5;
+req->data.regs.arm.arch.arm64.x6 = regs->x6;
+req->data.regs.arm.arch.arm64.x7 = regs->x7;
+req->data.regs.arm.arch.arm64.x8 = regs->x8;
+req->data.regs.arm.arch.arm64.x9 = regs->x9;
+req->data.regs.arm.arch.arm64.x10 = regs->x10;
+req->data.regs.arm.arch.arm64.x11 = regs->x11;
+req->data.regs.arm.arch.arm64.x12 = regs->x12;
+req->data.regs.arm.arch.arm64.x13 = regs->x13;
+req->data.regs.arm.arch.arm64.x14 = regs->x14;
+req->data.regs.arm.arch.arm64.x15 = regs->x15;
+req->data.regs.arm.arch.arm64.x16 = regs->x16;
+req->data.regs.arm.arch.arm64.x17 = regs->x17;
+req->data.regs.arm.arch.arm64.x18 = regs->x18;
+req->data.regs.arm.arch.arm64.x19 = regs->x19;
+req->data.regs.arm.arch.arm64.x20 = regs->x20;
+req->data.regs.arm.arch.arm64.x21 = regs->x21;
+req->data.regs.arm.arch.arm64.x22 = regs->x22;
+req->data.regs.arm.arch.arm64.x23 = regs->x23;
+req->data.regs.arm.arch.arm64.x24 = regs->x24;
+req->data.regs.arm.arch.arm64.x25 = regs->x25;
+req->data.regs.arm.arch.arm64.x26 = regs->x26;
+req->data.regs.arm.arch.arm64.x27 = regs->x27;
+req->data.regs.arm.arch.arm64.x28 = regs->x28;
+   

[Xen-devel] [PATCH v5 9/9] tools/xen-access: add test-case for ARM SMC

2016-06-02 Thread Tamas K Lengyel
Signed-off-by: Tamas K Lengyel 
Acked-by: Razvan Cojocaru 
Acked-by: Wei Liu 
---
Cc: Ian Jackson 
---
 tools/tests/xen-access/xen-access.c | 45 -
 1 file changed, 44 insertions(+), 1 deletion(-)

diff --git a/tools/tests/xen-access/xen-access.c 
b/tools/tests/xen-access/xen-access.c
index e615476..e467c48 100644
--- a/tools/tests/xen-access/xen-access.c
+++ b/tools/tests/xen-access/xen-access.c
@@ -338,6 +338,8 @@ void usage(char* progname)
 fprintf(stderr, "Usage: %s [-m]  write|exec", progname);
 #if defined(__i386__) || defined(__x86_64__)
 fprintf(stderr, "|breakpoint|altp2m_write|altp2m_exec|debug");
+#elif defined(__arm__) || defined(__aarch64__)
+fprintf(stderr, "|privcall");
 #endif
 fprintf(stderr,
 "\n"
@@ -426,6 +428,11 @@ int main(int argc, char *argv[])
 {
 debug = 1;
 }
+#elif defined(__arm__) || defined(__aarch64__)
+else if ( !strcmp(argv[0], "privcall") )
+{
+privcall = 1;
+}
 #endif
 else
 {
@@ -548,6 +555,16 @@ int main(int argc, char *argv[])
 }
 }
 
+if ( privcall )
+{
+rc = xc_monitor_privileged_call(xch, domain_id, 1);
+if ( rc < 0 )
+{
+ERROR("Error %d setting privileged call trapping with vm_event\n", 
rc);
+goto exit;
+}
+}
+
 /* Wait for access */
 for (;;)
 {
@@ -560,7 +577,8 @@ int main(int argc, char *argv[])
 rc = xc_monitor_software_breakpoint(xch, domain_id, 0);
 if ( debug )
 rc = xc_monitor_debug_exceptions(xch, domain_id, 0, 0);
-
+if ( privcall )
+rc = xc_monitor_privileged_call(xch, domain_id, 0);
 if ( altp2m )
 {
 rc = xc_altp2m_switch_to_view( xch, domain_id, 0 );
@@ -716,6 +734,31 @@ int main(int argc, char *argv[])
 }
 
 break;
+#if defined(__arm__) || defined(__aarch64__)
+case VM_EVENT_REASON_PRIVILEGED_CALL:
+{
+const struct vm_event_regs_arm *in_regs = 

+struct vm_event_regs_arm *out_regs = 
+bool is32bit = !!(in_regs->cpsr & PSR_MODE_BIT);
+uint64_t pc;
+
+*out_regs = *in_regs;
+
+if ( is32bit ) {
+pc = in_regs->arch.arm32.pc;
+out_regs->arch.arm32.pc += 4;
+} else {
+pc = in_regs->arch.arm64.pc;
+out_regs->arch.arm64.pc += 8;
+}
+
+printf("Privileged call: pc=%016"PRIx64" (vcpu %d)\n",
+   pc, req.vcpu_id);
+
+rsp.flags |= VM_EVENT_FLAG_SET_REGISTERS;
+}
+break;
+#endif
 default:
 fprintf(stderr, "UNKNOWN REASON CODE %d\n", req.reason);
 }
-- 
2.8.1


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


[Xen-devel] [PATCH v5 5/9] monitor: ARM SMC events

2016-06-02 Thread Tamas K Lengyel
Add support for monitoring ARM SMC events. This patch only adds the required
bits to enable/disable monitoring and forwarding the event through vm_event.

Signed-off-by: Tamas K Lengyel 
Acked-by: Razvan Cojocaru 
---
Cc: Stefano Stabellini 
Cc: Julien Grall 

v5: Add struct vm_event_privcall to hold the SMM call# (ESR_EL2.iss)
v4: Style fixes
v3: Split parts off as separate patches
Union for arm32/64 register structs in vm_event
Cosmetic fixes
---
 xen/arch/arm/Makefile |  1 +
 xen/arch/arm/monitor.c| 84 +++
 xen/arch/arm/traps.c  | 13 +--
 xen/include/asm-arm/domain.h  |  5 +++
 xen/include/asm-arm/monitor.h | 24 -
 xen/include/public/domctl.h   |  1 +
 xen/include/public/vm_event.h | 10 ++
 7 files changed, 118 insertions(+), 20 deletions(-)
 create mode 100644 xen/arch/arm/monitor.c

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index ead0cc0..344d3ad 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -41,6 +41,7 @@ obj-y += decode.o
 obj-y += processor.o
 obj-y += smc.o
 obj-$(CONFIG_XSPLICE) += xsplice.o
+obj-y += monitor.o
 
 #obj-bin-y += o
 
diff --git a/xen/arch/arm/monitor.c b/xen/arch/arm/monitor.c
new file mode 100644
index 000..90a13dd
--- /dev/null
+++ b/xen/arch/arm/monitor.c
@@ -0,0 +1,84 @@
+/*
+ * arch/arm/monitor.c
+ *
+ * Arch-specific monitor_op domctl handler.
+ *
+ * Copyright (c) 2016 Tamas K Lengyel (ta...@tklengyel.com)
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this program; If not, see .
+ */
+
+#include 
+#include 
+
+int arch_monitor_domctl_event(struct domain *d,
+  struct xen_domctl_monitor_op *mop)
+{
+struct arch_domain *ad = >arch;
+bool_t requested_status = (XEN_DOMCTL_MONITOR_OP_ENABLE == mop->op);
+
+switch ( mop->event )
+{
+case XEN_DOMCTL_MONITOR_EVENT_PRIVILEGED_CALL:
+{
+bool_t old_status = ad->monitor.privileged_call_enabled;
+
+if ( unlikely(old_status == requested_status) )
+return -EEXIST;
+
+domain_pause(d);
+ad->monitor.privileged_call_enabled = requested_status;
+domain_unpause(d);
+break;
+}
+
+default:
+/*
+ * Should not be reached unless arch_monitor_get_capabilities() is
+ * not properly implemented.
+ */
+ASSERT_UNREACHABLE();
+return -EOPNOTSUPP;
+}
+
+return 0;
+}
+
+bool_t monitor_smc(unsigned long iss, const struct cpu_user_regs *regs)
+{
+struct vcpu *curr = current;
+
+if ( curr->domain->arch.monitor.privileged_call_enabled )
+{
+vm_event_request_t req = { 0 };
+
+req.reason = VM_EVENT_REASON_PRIVILEGED_CALL;
+req.vcpu_id = curr->vcpu_id;
+req.u.privcall.type = VM_EVENT_PRIVCALL_SMC;
+req.u.privcall.vector = iss;
+
+if ( vm_event_monitor_traps(curr, 1, ) > 0 )
+return 1;
+}
+
+return 0;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index aa3e3c2..965c151 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -42,6 +42,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "decode.h"
 #include "vtimer.h"
@@ -2506,6 +2507,14 @@ bad_data_abort:
 inject_dabt_exception(regs, info.gva, hsr.len);
 }
 
+static void do_trap_smc(struct cpu_user_regs *regs, const union hsr hsr)
+{
+bool_t handled = monitor_smc(hsr.iss, regs);
+
+if ( !handled )
+inject_undef_exception(regs, hsr);
+}
+
 static void enter_hypervisor_head(struct cpu_user_regs *regs)
 {
 if ( guest_mode(regs) )
@@ -2581,7 +2590,7 @@ asmlinkage void do_trap_hypervisor(struct cpu_user_regs 
*regs)
  */
 GUEST_BUG_ON(!psr_mode_is_32bit(regs->cpsr));
 perfc_incr(trap_smc32);
-inject_undef32_exception(regs);
+do_trap_smc(regs, hsr);
 break;
 case HSR_EC_HVC32:
 GUEST_BUG_ON(!psr_mode_is_32bit(regs->cpsr));
@@ -2614,7 +2623,7 @@ asmlinkage void do_trap_hypervisor(struct cpu_user_regs 
*regs)
  */
 GUEST_BUG_ON(psr_mode_is_32bit(regs->cpsr));
 perfc_incr(trap_smc64);
-inject_undef64_exception(regs, hsr.len);
+do_trap_smc(regs, hsr);
 break;
   

[Xen-devel] [PATCH v5 1/9] vm_event: clear up return value of vm_event_monitor_traps

2016-06-02 Thread Tamas K Lengyel
The return value has not been clearly defined, with the function
never returning 0 which seemingly indicated a condition where the
guest should crash. In this patch we define -rc as error condition
where the notification was not sent, 0 where the notification was sent
and the vCPU is not paused and 1 that the notification was sent and
that the vCPU is paused.

Signed-off-by: Tamas K Lengyel 
---
Cc: Jun Nakajima 
Cc: Kevin Tian 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Razvan Cojocaru 
---
 xen/arch/x86/hvm/event.c   | 4 ++--
 xen/arch/x86/hvm/vmx/vmx.c | 6 +++---
 xen/common/vm_event.c  | 5 +++--
 3 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/xen/arch/x86/hvm/event.c b/xen/arch/x86/hvm/event.c
index 56c5514..5772c6b 100644
--- a/xen/arch/x86/hvm/event.c
+++ b/xen/arch/x86/hvm/event.c
@@ -47,8 +47,8 @@ bool_t hvm_event_cr(unsigned int index, unsigned long value, 
unsigned long old)
 .u.write_ctrlreg.old_value = old
 };
 
-vm_event_monitor_traps(curr, sync, );
-return 1;
+if ( vm_event_monitor_traps(curr, sync, ) >= 0 )
+return 1;
 }
 
 return 0;
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 3acf1ab..097d97c 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -3392,11 +3392,11 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
 break;
 }
 else {
-int handled =
+int rc =
 hvm_event_breakpoint(regs->eip,
  HVM_EVENT_SOFTWARE_BREAKPOINT);
 
-if ( handled < 0 ) 
+if ( !rc )
 {
 struct hvm_trap trap = {
 .vector = TRAP_int3,
@@ -3410,7 +3410,7 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
 hvm_inject_trap();
 break;
 }
-else if ( handled )
+else if ( rc > 0 )
 break;
 }
 
diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c
index 2906407..fe86fb9 100644
--- a/xen/common/vm_event.c
+++ b/xen/common/vm_event.c
@@ -801,7 +801,7 @@ int vm_event_monitor_traps(struct vcpu *v, uint8_t sync,
  * If there was no ring to handle the event, then
  * simply continue executing normally.
  */
-return 1;
+return 0;
 default:
 return rc;
 };
@@ -810,6 +810,7 @@ int vm_event_monitor_traps(struct vcpu *v, uint8_t sync,
 {
 req->flags |= VM_EVENT_FLAG_VCPU_PAUSED;
 vm_event_vcpu_pause(v);
+rc = 1;
 }
 
 if ( altp2m_active(d) )
@@ -821,7 +822,7 @@ int vm_event_monitor_traps(struct vcpu *v, uint8_t sync,
 vm_event_fill_regs(req);
 vm_event_put_request(d, >vm_event->monitor, req);
 
-return 1;
+return rc;
 }
 
 void vm_event_monitor_guest_request(void)
-- 
2.8.1


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


[Xen-devel] [PATCH v5 3/9] monitor: Rename vm_event_monitor_guest_request

2016-06-02 Thread Tamas K Lengyel
Mechanical renaming and relocation to the monitor subsystem.

Signed-off-by: Tamas K Lengyel 
Acked-by: Razvan Cojocaru 
Acked-by: Jan Beulich 
---
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: Andrew Cooper 
---
 xen/arch/arm/hvm.c |  4 ++--
 xen/arch/x86/hvm/hvm.c |  3 ++-
 xen/common/monitor.c   | 17 +
 xen/common/vm_event.c  | 16 
 xen/include/xen/monitor.h  |  1 +
 xen/include/xen/vm_event.h |  2 --
 6 files changed, 22 insertions(+), 21 deletions(-)

diff --git a/xen/arch/arm/hvm.c b/xen/arch/arm/hvm.c
index c01123a..d999bde 100644
--- a/xen/arch/arm/hvm.c
+++ b/xen/arch/arm/hvm.c
@@ -22,7 +22,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include 
 
@@ -75,7 +75,7 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) 
arg)
 
 case HVMOP_guest_request_vm_event:
 if ( guest_handle_is_null(arg) )
-vm_event_monitor_guest_request();
+monitor_guest_request();
 else
 rc = -EINVAL;
 break;
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 5040a5c..7bf6a36 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -37,6 +37,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -5704,7 +5705,7 @@ long do_hvm_op(unsigned long op, 
XEN_GUEST_HANDLE_PARAM(void) arg)
 
 case HVMOP_guest_request_vm_event:
 if ( guest_handle_is_null(arg) )
-vm_event_monitor_guest_request();
+monitor_guest_request();
 else
 rc = -EINVAL;
 break;
diff --git a/xen/common/monitor.c b/xen/common/monitor.c
index 7c3d1c8..436214a 100644
--- a/xen/common/monitor.c
+++ b/xen/common/monitor.c
@@ -21,6 +21,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -84,6 +85,22 @@ int monitor_domctl(struct domain *d, struct 
xen_domctl_monitor_op *mop)
 return 0;
 }
 
+void monitor_guest_request(void)
+{
+struct vcpu *curr = current;
+struct domain *d = curr->domain;
+
+if ( d->monitor.guest_request_enabled )
+{
+vm_event_request_t req = {
+.reason = VM_EVENT_REASON_GUEST_REQUEST,
+.vcpu_id = curr->vcpu_id,
+};
+
+vm_event_monitor_traps(curr, d->monitor.guest_request_sync, );
+}
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c
index fe86fb9..068d587 100644
--- a/xen/common/vm_event.c
+++ b/xen/common/vm_event.c
@@ -825,22 +825,6 @@ int vm_event_monitor_traps(struct vcpu *v, uint8_t sync,
 return rc;
 }
 
-void vm_event_monitor_guest_request(void)
-{
-struct vcpu *curr = current;
-struct domain *d = curr->domain;
-
-if ( d->monitor.guest_request_enabled )
-{
-vm_event_request_t req = {
-.reason = VM_EVENT_REASON_GUEST_REQUEST,
-.vcpu_id = curr->vcpu_id,
-};
-
-vm_event_monitor_traps(curr, d->monitor.guest_request_sync, );
-}
-}
-
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/xen/monitor.h b/xen/include/xen/monitor.h
index 7015e6d..204d5cc 100644
--- a/xen/include/xen/monitor.h
+++ b/xen/include/xen/monitor.h
@@ -26,5 +26,6 @@ struct domain;
 struct xen_domctl_monitor_op;
 
 int monitor_domctl(struct domain *d, struct xen_domctl_monitor_op *op);
+void monitor_guest_request(void);
 
 #endif /* __XEN_MONITOR_H__ */
diff --git a/xen/include/xen/vm_event.h b/xen/include/xen/vm_event.h
index beda9fe..89e6243 100644
--- a/xen/include/xen/vm_event.h
+++ b/xen/include/xen/vm_event.h
@@ -81,8 +81,6 @@ void vm_event_vcpu_unpause(struct vcpu *v);
 int vm_event_monitor_traps(struct vcpu *v, uint8_t sync,
vm_event_request_t *req);
 
-void vm_event_monitor_guest_request(void);
-
 #endif /* __VM_EVENT_H__ */
 
 
-- 
2.8.1


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


[Xen-devel] [PATCH v5 7/9] tools/libxc: add xc_monitor_privileged_call

2016-06-02 Thread Tamas K Lengyel
These are the user-space components for the new ARM SMC events.

Signed-off-by: Tamas K Lengyel 
Acked-by: Wei Liu 
---
Cc: Ian Jackson 
---
 tools/libxc/include/xenctrl.h |  2 ++
 tools/libxc/xc_monitor.c  | 24 
 2 files changed, 26 insertions(+)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index dc54612..3085130 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2160,6 +2160,8 @@ int xc_monitor_software_breakpoint(xc_interface *xch, 
domid_t domain_id,
bool enable);
 int xc_monitor_guest_request(xc_interface *xch, domid_t domain_id,
  bool enable, bool sync);
+int xc_monitor_privileged_call(xc_interface *xch, domid_t domain_id,
+   bool enable);
 
 /**
  * This function enables / disables emulation for each REP for a
diff --git a/tools/libxc/xc_monitor.c b/tools/libxc/xc_monitor.c
index b1705dd..1e4a9d2 100644
--- a/tools/libxc/xc_monitor.c
+++ b/tools/libxc/xc_monitor.c
@@ -156,3 +156,27 @@ int xc_monitor_emulate_each_rep(xc_interface *xch, domid_t 
domain_id,
 
 return do_domctl(xch, );
 }
+
+int xc_monitor_privileged_call(xc_interface *xch, domid_t domain_id,
+   bool enable)
+{
+DECLARE_DOMCTL;
+
+domctl.cmd = XEN_DOMCTL_monitor_op;
+domctl.domain = domain_id;
+domctl.u.monitor_op.op = enable ? XEN_DOMCTL_MONITOR_OP_ENABLE
+: XEN_DOMCTL_MONITOR_OP_DISABLE;
+domctl.u.monitor_op.event = XEN_DOMCTL_MONITOR_EVENT_PRIVILEGED_CALL;
+
+return do_domctl(xch, );
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.8.1


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


[Xen-devel] [PATCH v5 8/9] x86/vm_event: Add HVM debug exception vm_events

2016-06-02 Thread Tamas K Lengyel
Since in-guest debug exceptions are now unconditionally trapped to Xen, adding
a hook for vm_event subscribers to tap into this new always-on guest event. We
rename along the way hvm_event_breakpoint_type to hvm_event_type to better
match the various events that can be passed with it. We also introduce the
necessary monitor_op domctl's to enable subscribing to the events.

Signed-off-by: Tamas K Lengyel 
---
Cc: Ian Jackson 
Cc: Wei Liu 
Cc: Razvan Cojocaru 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Jun Nakajima 
Cc: Kevin Tian 

v5: Transmit the proper insn_length for int3 events as well to fix
 the current bug with prefixed int3 instructions.
---
 tools/libxc/include/xenctrl.h   |  3 +-
 tools/libxc/xc_monitor.c| 15 +
 tools/tests/xen-access/xen-access.c | 63 -
 xen/arch/x86/hvm/monitor.c  | 21 +++--
 xen/arch/x86/hvm/vmx/vmx.c  | 47 +--
 xen/arch/x86/monitor.c  | 16 ++
 xen/include/asm-x86/domain.h|  2 ++
 xen/include/asm-x86/hvm/monitor.h   |  7 +++--
 xen/include/asm-x86/monitor.h   |  3 +-
 xen/include/public/domctl.h |  6 
 xen/include/public/vm_event.h   | 14 +++--
 11 files changed, 169 insertions(+), 28 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 3085130..29d983e 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2162,7 +2162,8 @@ int xc_monitor_guest_request(xc_interface *xch, domid_t 
domain_id,
  bool enable, bool sync);
 int xc_monitor_privileged_call(xc_interface *xch, domid_t domain_id,
bool enable);
-
+int xc_monitor_debug_exceptions(xc_interface *xch, domid_t domain_id,
+bool enable, bool sync);
 /**
  * This function enables / disables emulation for each REP for a
  * REP-compatible instruction.
diff --git a/tools/libxc/xc_monitor.c b/tools/libxc/xc_monitor.c
index 1e4a9d2..b0bf708 100644
--- a/tools/libxc/xc_monitor.c
+++ b/tools/libxc/xc_monitor.c
@@ -171,6 +171,21 @@ int xc_monitor_privileged_call(xc_interface *xch, domid_t 
domain_id,
 return do_domctl(xch, );
 }
 
+int xc_monitor_debug_exceptions(xc_interface *xch, domid_t domain_id,
+bool enable, bool sync)
+{
+DECLARE_DOMCTL;
+
+domctl.cmd = XEN_DOMCTL_monitor_op;
+domctl.domain = domain_id;
+domctl.u.monitor_op.op = enable ? XEN_DOMCTL_MONITOR_OP_ENABLE
+: XEN_DOMCTL_MONITOR_OP_DISABLE;
+domctl.u.monitor_op.event = XEN_DOMCTL_MONITOR_EVENT_DEBUG_EXCEPTION;
+domctl.u.monitor_op.u.debug_exception.sync = sync;
+
+return do_domctl(xch, );
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/tests/xen-access/xen-access.c 
b/tools/tests/xen-access/xen-access.c
index f26e723..e615476 100644
--- a/tools/tests/xen-access/xen-access.c
+++ b/tools/tests/xen-access/xen-access.c
@@ -53,6 +53,10 @@
 #define ERROR(a, b...) fprintf(stderr, a "\n", ## b)
 #define PERROR(a, b...) fprintf(stderr, a ": %s\n", ## b, strerror(errno))
 
+/* From xen/include/asm-x86/processor.h */
+#define X86_TRAP_DEBUG  1
+#define X86_TRAP_INT3   3
+
 typedef struct vm_event {
 domid_t domain_id;
 xenevtchn_handle *xce_handle;
@@ -333,7 +337,7 @@ void usage(char* progname)
 {
 fprintf(stderr, "Usage: %s [-m]  write|exec", progname);
 #if defined(__i386__) || defined(__x86_64__)
-fprintf(stderr, "|breakpoint|altp2m_write|altp2m_exec");
+fprintf(stderr, "|breakpoint|altp2m_write|altp2m_exec|debug");
 #endif
 fprintf(stderr,
 "\n"
@@ -354,10 +358,12 @@ int main(int argc, char *argv[])
 xc_interface *xch;
 xenmem_access_t default_access = XENMEM_access_rwx;
 xenmem_access_t after_first_access = XENMEM_access_rwx;
+int memaccess = 0;
 int required = 0;
 int breakpoint = 0;
 int shutting_down = 0;
 int altp2m = 0;
+int debug = 0;
 uint16_t altp2m_view_id = 0;
 
 char* progname = argv[0];
@@ -391,11 +397,13 @@ int main(int argc, char *argv[])
 {
 default_access = XENMEM_access_rx;
 after_first_access = XENMEM_access_rwx;
+memaccess = 1;
 }
 else if ( !strcmp(argv[0], "exec") )
 {
 default_access = XENMEM_access_rw;
 after_first_access = XENMEM_access_rwx;
+memaccess = 1;
 }
 #if defined(__i386__) || defined(__x86_64__)
 else if ( !strcmp(argv[0], "breakpoint") )
@@ -406,11 +414,17 @@ int main(int argc, char *argv[])
 {
 default_access = XENMEM_access_rx;
 altp2m = 1;
+memaccess = 1;
 }
 else if ( !strcmp(argv[0], "altp2m_exec") )
 {
 

[Xen-devel] [PATCH v5 2/9] monitor: Rename vm_event_monitor_get_capabilities

2016-06-02 Thread Tamas K Lengyel
The monitor_get_capabilities check actually belongs to the monitor subsystem so
relocating and renaming it to sanitize the code's name and location. Mechanical
patch, no code changes introduced.

Signed-off-by: Tamas K Lengyel 
Acked-by: Andrew Cooper 
Acked-by: Razvan Cojocaru 
---
Cc: Jan Beulich 
Cc: Stefano Stabellini 
Cc: Julien Grall 
---
 xen/arch/x86/monitor.c |  2 +-
 xen/common/monitor.c   |  5 ++---
 xen/include/asm-arm/monitor.h  | 11 ++-
 xen/include/asm-arm/vm_event.h |  9 -
 xen/include/asm-x86/monitor.h  | 23 +++
 xen/include/asm-x86/vm_event.h | 23 ---
 6 files changed, 36 insertions(+), 37 deletions(-)

diff --git a/xen/arch/x86/monitor.c b/xen/arch/x86/monitor.c
index 1fec412..621f91a 100644
--- a/xen/arch/x86/monitor.c
+++ b/xen/arch/x86/monitor.c
@@ -126,7 +126,7 @@ int arch_monitor_domctl_event(struct domain *d,
 
 default:
 /*
- * Should not be reached unless vm_event_monitor_get_capabilities() is
+ * Should not be reached unless arch_monitor_get_capabilities() is
  * not properly implemented.
  */
 ASSERT_UNREACHABLE();
diff --git a/xen/common/monitor.c b/xen/common/monitor.c
index d950a7c..7c3d1c8 100644
--- a/xen/common/monitor.c
+++ b/xen/common/monitor.c
@@ -24,7 +24,6 @@
 #include 
 #include 
 #include 
-#include 
 
 int monitor_domctl(struct domain *d, struct xen_domctl_monitor_op *mop)
 {
@@ -48,12 +47,12 @@ int monitor_domctl(struct domain *d, struct 
xen_domctl_monitor_op *mop)
 if ( unlikely(mop->event > 31) )
 return -EINVAL;
 /* Check if event type is available. */
-if ( unlikely(!(vm_event_monitor_get_capabilities(d) & (1U << 
mop->event))) )
+if ( unlikely(!(arch_monitor_get_capabilities(d) & (1U << 
mop->event))) )
 return -EOPNOTSUPP;
 break;
 
 case XEN_DOMCTL_MONITOR_OP_GET_CAPABILITIES:
-mop->event = vm_event_monitor_get_capabilities(d);
+mop->event = arch_monitor_get_capabilities(d);
 return 0;
 
 default:
diff --git a/xen/include/asm-arm/monitor.h b/xen/include/asm-arm/monitor.h
index 6e36e99..3fd3c9d 100644
--- a/xen/include/asm-arm/monitor.h
+++ b/xen/include/asm-arm/monitor.h
@@ -39,11 +39,20 @@ int arch_monitor_domctl_event(struct domain *d,
 /*
  * No arch-specific monitor vm-events on ARM.
  *
- * Should not be reached unless vm_event_monitor_get_capabilities() is not
+ * Should not be reached unless arch_monitor_get_capabilities() is not
  * properly implemented.
  */
 ASSERT_UNREACHABLE();
 return -EOPNOTSUPP;
 }
 
+static inline uint32_t arch_monitor_get_capabilities(struct domain *d)
+{
+uint32_t capabilities = 0;
+
+capabilities = (1U << XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST);
+
+return capabilities;
+}
+
 #endif /* __ASM_ARM_MONITOR_H__ */
diff --git a/xen/include/asm-arm/vm_event.h b/xen/include/asm-arm/vm_event.h
index 014d9ba..a3fc4ce 100644
--- a/xen/include/asm-arm/vm_event.h
+++ b/xen/include/asm-arm/vm_event.h
@@ -59,13 +59,4 @@ static inline void vm_event_fill_regs(vm_event_request_t 
*req)
 /* Not supported on ARM. */
 }
 
-static inline uint32_t vm_event_monitor_get_capabilities(struct domain *d)
-{
-uint32_t capabilities = 0;
-
-capabilities = (1U << XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST);
-
-return capabilities;
-}
-
 #endif /* __ASM_ARM_VM_EVENT_H__ */
diff --git a/xen/include/asm-x86/monitor.h b/xen/include/asm-x86/monitor.h
index d367099..0fee750 100644
--- a/xen/include/asm-x86/monitor.h
+++ b/xen/include/asm-x86/monitor.h
@@ -60,4 +60,27 @@ int arch_monitor_domctl_op(struct domain *d, struct 
xen_domctl_monitor_op *mop)
 int arch_monitor_domctl_event(struct domain *d,
   struct xen_domctl_monitor_op *mop);
 
+static inline uint32_t arch_monitor_get_capabilities(struct domain *d)
+{
+uint32_t capabilities = 0;
+
+/*
+ * At the moment only Intel HVM domains are supported. However, event
+ * delivery could be extended to AMD and PV domains.
+ */
+if ( !is_hvm_domain(d) || !cpu_has_vmx )
+return capabilities;
+
+capabilities = (1U << XEN_DOMCTL_MONITOR_EVENT_WRITE_CTRLREG) |
+   (1U << XEN_DOMCTL_MONITOR_EVENT_MOV_TO_MSR) |
+   (1U << XEN_DOMCTL_MONITOR_EVENT_SOFTWARE_BREAKPOINT) |
+   (1U << XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST);
+
+/* Since we know this is on VMX, we can just call the hvm func */
+if ( hvm_is_singlestep_supported() )
+capabilities |= (1U << XEN_DOMCTL_MONITOR_EVENT_SINGLESTEP);
+
+return capabilities;
+}
+
 #endif /* __ASM_X86_MONITOR_H__ */
diff --git a/xen/include/asm-x86/vm_event.h b/xen/include/asm-x86/vm_event.h
index 0470240..026f42e 100644
--- 

Re: [Xen-devel] [PATCH v4 4/8] monitor: ARM SMC events

2016-06-02 Thread Tamas K Lengyel
On Thu, Jun 2, 2016 at 8:23 AM, Julien Grall  wrote:
>
> Hello Tamas,
>
> On 01/06/16 16:41, Tamas K Lengyel wrote:
>>
>>
>> On Jun 1, 2016 05:37, "Julien Grall" > > wrote:
>>  > On 29/05/16 23:37, Tamas K Lengyel wrote:
>>  >>
>>  >> Add support for monitoring ARM SMC events. This patch only adds the
>> required
>>  >> bits to enable/disable monitoring and forwarding the event through
>> vm_event.
>>  >
>>  >
>>  > Couple of questions:
>>  >
>>  > - How the vm-event app will differentiate a SMC64 vs a SMC32 call?
>>
>> Wouldn't cpsr record the guest state when the smc was executed, telling
>> us whether it was 32bit or 64bit?
>
>
> You are right.
>
>>  > - How the vm-event app will know the SMC number (i.e the
>>  >
>>  > In an AArch64 state, those informations are available from the
>> syndrome register (HSR_EL2.ISS).
>>
>> Good question, it should probably be sent alongside the other registers.
>> At the moment my usecase doesn't care about it as I'm just using SMC for
>> inducing traps to the vmm but other applications may indeed need this.
>
>
> In this case, we should either provide HSR_EL2, or decode it provide the
> value.
>
> Note that HSR_EL2.ISS is unknown for ARMv7 (see B3-1431 in ARM DDI 0406C.c).
>
> On ARMv8, ESR_EL2.ISS has a different encoding depending on the state (i.e
> AArch64 or AArch32). See D7-1861 in ARM DDI 0487A.i. Furthermore, in AArch32
> state, the ARMv8 specs permits to trap conditional SMC instructions that
> fail their condition check (see D7-1897 in ARM DDI 0406C.c).
>
> So I guess, this need to be abstract in Xen to avoid burden to the
> introspection app.

So during the trap ESR_EL2 is already read into const union hsr hsr,
so my thinking was to just submit hsr.iss to the introspection app and
let it deal with decoding it if it needs to.

Tamas

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


[Xen-devel] [seabios test] 95197: tolerable FAIL - PUSHED

2016-06-02 Thread osstest service owner
flight 95197 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95197/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 95124
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 95124

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass

version targeted for testing:
 seabios  d97c200c6e2bf69f32857937e1f278134b392e2a
baseline version:
 seabios  04259c5817edc6d23f0aed76fd20ab220efcddc6

Last test of basis95124  2016-06-01 09:43:00 Z1 days
Testing same since95197  2016-06-02 13:13:00 Z0 days1 attempts


People who touched revisions under test:
  Kevin O'Connor 
  Zheng Bao 
  Zheng Bao 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-qemuu-nested-intel  pass
 test-amd64-i386-qemuu-rhel6hvm-intel pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
 test-amd64-amd64-xl-qemuu-winxpsp3   pass
 test-amd64-i386-xl-qemuu-winxpsp3pass



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

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

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

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


Pushing revision :

+ branch=seabios
+ revision=d97c200c6e2bf69f32857937e1f278134b392e2a
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push seabios 
d97c200c6e2bf69f32857937e1f278134b392e2a
+ branch=seabios
+ revision=d97c200c6e2bf69f32857937e1f278134b392e2a
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=seabios
+ 

[Xen-devel] [PATCH livepatch-tools] Rename of xSplice to LivePatch.

2016-06-02 Thread Konrad Rzeszutek Wilk
s/xsplice/livepatch/
s/XSPLICE/LIVEPATCH/
s/xSplice/LivePatch/

Signed-off-by: Konrad Rzeszutek Wilk 
---
 README.md| 26 -
 common.h |  2 +-
 create-diff-object.c | 42 
 xsplice-build => livepatch-build | 32 +++---
 xsplice-gcc => livepatch-gcc | 12 ++--
 prelink.c|  4 ++--
 6 files changed, 59 insertions(+), 59 deletions(-)
 rename xsplice-build => livepatch-build (90%)
 rename xsplice-gcc => livepatch-gcc (80%)

diff --git a/README.md b/README.md
index c39b376..9fb709f 100644
--- a/README.md
+++ b/README.md
@@ -1,9 +1,9 @@
-xsplice-build
+livepatch-build
 =
 
-xsplice-build is a tool for building xSplice patches from source code
+livepatch-build is a tool for building LivePatch patches from source code
 patches.  It takes as input, a Xen tree and a patch and outputs an
-`.xsplice` module containing containing the live patch.
+`.livepatch` module containing containing the live patch.
 
 Quick start
 ---
@@ -15,14 +15,14 @@ $ cd ~/src/xen
 $ git reset --hard
 $ git clean -x -f -d
 $ git checkout 346d4545569928b652c40c7815c1732676f8587c^
-$ cd ~/src/xsplice-build
+$ cd ~/src/livepatch-build
 $ wget -q 'http://xenbits.xen.org/xsa/xsa106.patch'
-$ ./xsplice-build --xen-debug -s ~/src/xen -p xsa106.patch -o out
-Building xSplice patch: xsa106
+$ ./livepatch-build --xen-debug -s ~/src/xen -p xsa106.patch -o out
+Building LivePatch patch: xsa106
 
 Xen directory: /home/ross/src/xen
-Patch file: /home/ross/src/xsplice-build/xsa106.patch
-Output directory: /home/ross/src/xsplice-build/out
+Patch file: /home/ross/src/livepatch-build/xsa106.patch
+Output directory: /home/ross/src/livepatch-build/out
 
 
 Testing patch file...
@@ -32,10 +32,10 @@ Unapply patch and build with 4 CPU(s)...
 Extracting new and modified ELF sections...
 Processing xen/arch/x86/x86_emulate.o
 Creating patch module...
-xsa106.xsplice created successfully
+xsa106.livepatch created successfully
 
-$ ls -lh out/xsa106.xsplice
--rw-rw-r--. 1 ross ross 418K Oct 12 12:02 out/xsa106.xsplice
+$ ls -lh out/xsa106.livepatch
+-rw-rw-r--. 1 ross ross 418K Oct 12 12:02 out/xsa106.livepatch
 ```
 
 Project Status
@@ -43,7 +43,7 @@ Project Status
 This is prototype code:
  * There's no way to apply built patches
  * Patches cannot be built for some source patches
- * The output format does not correspond to the latest xSplice design
+ * The output format does not correspond to the latest LivePatch design
 
 With no source patch modifications, live patches can be built for every
 XSA that applies to x86 back to XSA-90 except for XSA-97, XSA-111,
@@ -51,7 +51,7 @@ XSA-112, and XSA-114 (83% success rate).
 
 License
 ---
-xSplice is under the GPLv2 license.
+LivePatch is under the GPLv2 license.
 
 This program is free software; you can redistribute it and/or
 modify it under the terms of the GNU General Public License
diff --git a/common.h b/common.h
index d76881c..7599fe7 100644
--- a/common.h
+++ b/common.h
@@ -116,7 +116,7 @@ struct kpatch_elf {
 
 #define PATCH_INSN_SIZE 5
 
-struct xsplice_patch_func {
+struct livepatch_patch_func {
char *name;
unsigned long new_addr;
unsigned long old_addr;
diff --git a/create-diff-object.c b/create-diff-object.c
index 0488556..69bcd88 100644
--- a/create-diff-object.c
+++ b/create-diff-object.c
@@ -860,7 +860,7 @@ static void kpatch_mark_ignored_functions_same(struct 
kpatch_elf *kelf)
struct section *sec;
struct rela *rela;
 
-   sec = find_section_by_name(>sections, 
".xsplice.ignore.functions");
+   sec = find_section_by_name(>sections, 
".livepatch.ignore.functions");
if (!sec)
return;
 
@@ -887,7 +887,7 @@ static void kpatch_mark_ignored_sections(struct kpatch_elf 
*kelf)
struct rela *rela;
char *name;
 
-   sec = find_section_by_name(>sections, ".xsplice.ignore.sections");
+   sec = find_section_by_name(>sections, 
".livepatch.ignore.sections");
if (!sec)
return;
 
@@ -1297,10 +1297,10 @@ static void kpatch_include_hook_elements(struct 
kpatch_elf *kelf)
 
/* include load/unload sections */
list_for_each_entry(sec, >sections, list) {
-   if (!strcmp(sec->name, ".xsplice.hooks.load") ||
-   !strcmp(sec->name, ".xsplice.hooks.unload") ||
-   !strcmp(sec->name, ".rela.xsplice.hooks.load") ||
-   !strcmp(sec->name, ".rela.xsplice.hooks.unload")) {
+   if (!strcmp(sec->name, ".livepatch.hooks.load") ||
+   !strcmp(sec->name, ".livepatch.hooks.unload") ||
+   !strcmp(sec->name, ".rela.livepatch.hooks.load") ||
+   !strcmp(sec->name, ".rela.livepatch.hooks.unload")) {

Re: [Xen-devel] Issues with PCI-Passtrough (VT-d) in HVM with Xen 4.6

2016-06-02 Thread Sylwester Sosnowski

On 02.06.16 um 22:06 Konrad Rzeszutek Wilk wrote:
>> did you try the permissive module parameter?

Yes, I have been using the permissive mode when
I was getting these results.

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


Re: [Xen-devel] [PATCH v1 for 4.7] Tmem cleanups.

2016-06-02 Thread Konrad Rzeszutek Wilk
> > If you confirm that it builds on Debian Jessie, that would be good
> > enough for me:
> 
> Sure thing. Will make sure and if there are no issues will
> push it in staging.

Confirmed. No issues building on Jessie.
> 
> Thanks!
> > 
> > Release-acked-by: Wei Liu 
> > 
> > > Konrad Rzeszutek Wilk (4):
> > >   tmem: Move global stats in a tmem_statistics structure
> > >   tmem: Wrap atomic_t in struct tmem_statistics as well.
> > >   tmem: Move global_ individual variables in a global structure.
> > >   tmem: Move bulk of tmem control functions in its own file.
> > > 
> > > ___
> > > 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] Issues with PCI-Passtrough (VT-d) in HVM with Xen 4.6

2016-06-02 Thread Konrad Rzeszutek Wilk
On Thu, Jun 02, 2016 at 09:59:29PM +0200, Sylwester Sosnowski wrote:
> 
> Issues with PCI-Passtrough (VT-d) in HVM with Xen 4.6
> =
> 
> Background
> --
> 
> I am trying to passthrough an Industrial Ethernet Interface
> (Hilscher GmbH CIFX 50E-DP(M/S)) on a HVM DomU running the
> Xen 4.6 Hypervisor. The card is being pass-trough to the HVM
> using the PCI permissive mode and VT-d is active on this platform.
> 
> The Linux driver of the card (available only with NDA) at first
> sight seems to work properly (e.g. no system stability problems,
> no call traces in dmesg).
> 
> Hilscher provides the libcifx, which is an user-level library
> for accessing the card. libcfix uses the generic UIO interface
> and some card-specific interfaces to communicate.
> 
> Issue
> -
> 
> Whenever libcifx tries perform a reset sequence initializing
> the card peripherals, we get an empty / invalid result.
> 
> I digged deeper into this by adding some debug hooks into the
> xen-pciback kernel module.
> 
> The card performs writes to offset 0x10 and 0x30 at card
> initialization (mostly writing dwords and words).
> 
> To verify if the writes were performed successfully, I read
> back the values after writing and can see that the read data
> differs from the written one.
> 
> Temporary Fix
> -
> 
> After checking the source[1] of the PCI configuration space
> handling in xen-pciback, I found out that changing line 258
> to read
> 
> if (handled && !err) {
> 
> instead of:
> 
> if (!handled && !err) {
> 
> solves the issue and I can successfully write to the interface.
> 
> I am unsure why this works and if it's the right way to do it
> or possibly a Xen bug, so I would like to ask for feedback
> for this.

did you try the permissive module parameter?
> 
> 
> Please let me know whenever I can supply additional logfiles or
> info. I'd be happy if we can resolve whenever this is a hardware-
> specific, driver-specific or Xen issue.
> 
> Thank you,
> Sylwester
> 
> PS: I tried to CC Ryan Wilson and Konrad Rzeszutek Wilk, but the
> E-Mail seems to be no longer active. This is where the changes
> originated.
> 
> Refereces
> -
> 1.
> https://github.com/google/kasan/blob/master/drivers/xen/xen-pciback/conf_space.c

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


[Xen-devel] Issues with PCI-Passtrough (VT-d) in HVM with Xen 4.6

2016-06-02 Thread Sylwester Sosnowski

Issues with PCI-Passtrough (VT-d) in HVM with Xen 4.6
=

Background
--

I am trying to passthrough an Industrial Ethernet Interface
(Hilscher GmbH CIFX 50E-DP(M/S)) on a HVM DomU running the
Xen 4.6 Hypervisor. The card is being pass-trough to the HVM
using the PCI permissive mode and VT-d is active on this platform.

The Linux driver of the card (available only with NDA) at first
sight seems to work properly (e.g. no system stability problems,
no call traces in dmesg).

Hilscher provides the libcifx, which is an user-level library
for accessing the card. libcfix uses the generic UIO interface
and some card-specific interfaces to communicate.

Issue
-

Whenever libcifx tries perform a reset sequence initializing
the card peripherals, we get an empty / invalid result.

I digged deeper into this by adding some debug hooks into the
xen-pciback kernel module.

The card performs writes to offset 0x10 and 0x30 at card
initialization (mostly writing dwords and words).

To verify if the writes were performed successfully, I read
back the values after writing and can see that the read data
differs from the written one.

Temporary Fix
-

After checking the source[1] of the PCI configuration space
handling in xen-pciback, I found out that changing line 258
to read

if (handled && !err) {

instead of:

if (!handled && !err) {

solves the issue and I can successfully write to the interface.

I am unsure why this works and if it's the right way to do it
or possibly a Xen bug, so I would like to ask for feedback
for this.


Please let me know whenever I can supply additional logfiles or
info. I'd be happy if we can resolve whenever this is a hardware-
specific, driver-specific or Xen issue.

Thank you,
Sylwester

PS: I tried to CC Ryan Wilson and Konrad Rzeszutek Wilk, but the
E-Mail seems to be no longer active. This is where the changes
originated.

Refereces
-
1.
https://github.com/google/kasan/blob/master/drivers/xen/xen-pciback/conf_space.c

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


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

2016-06-02 Thread osstest service owner
flight 95183 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95183/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail REGR. vs. 
94856
 test-amd64-amd64-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail REGR. vs. 
94856
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 15 guest-localmigrate/x10 fail REGR. 
vs. 94856

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-arndale   6 xen-boot   fail in 95089 pass in 95183
 test-amd64-amd64-xl-rtds  6 xen-boot   fail in 95089 pass in 95183
 test-amd64-i386-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail pass in 95089

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 13 guest-localmigrate fail REGR. vs. 94856
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-localmigrate fail REGR. vs. 94856
 test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail blocked in 94856
 test-amd64-amd64-xl-rtds  9 debian-install   fail   like 94856

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass

version targeted for testing:
 qemuu500acc9c410bcea17148a1072e323c08d12e6a6b
baseline version:
 qemuud6550e9ed2e1a60d889dfb721de00d9a4e3bafbe

Last test of basis94856  2016-05-27 20:14:49 Z5 days
Failing since 94983  2016-05-31 09:40:12 Z2 days6 attempts
Testing same since94994  2016-05-31 15:42:55 Z2 days5 attempts


People who touched revisions under test:
  Anthony PERARD 
  Benjamin Herrenschmidt 
  Bharata B Rao 
  Chen Fan 
  Cédric Le Goater 
  David Gibson 
  Drew Jones 
  Emilio G. Cota 
  Eric Blake 
  Fam Zheng 
  Gu Zheng 
  Michael Neuling 
  Michael Walle 
  Paolo Bonzini 
  Paul Durrant 

Re: [Xen-devel] Basic bare metal ARM domain interface

2016-06-02 Thread Ivan Pavic
Hello Julien,

On Thu, Jun 02, 2016 at 12:41:02PM +0100, Julien Grall wrote:
> 
> Which compiler led to use a data abort? And where was the data
> abort? In Xen or the guest?
>

When I compile app directly on ODROID I used:
arm-linux-gnueabihf
gcc version 4.8.4 (Ubuntu/Linaro 4.8.4-2ubuntu1~14.04.1) 

HVC instruction works form assembler, but when I call it from main, for
example: 
HYPERVISOR_console_io (HYPERCALL_WRITE, SYSTEM_UP_LEN, SYSTEM_UP_MSG);
then I get this in xl dmesg:
traps.c:2450:d2v0 HSR=0x9046 pc=0x40008250 gva=0 gpa=

This doesn't happen with other compiler. 

Regards, 

Ivan Pavic

 


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


Re: [Xen-devel] Discussion about virtual iommu support for Xen guest

2016-06-02 Thread Andrew Cooper
On 02/06/16 16:03, Lan, Tianyu wrote:
> On 5/27/2016 4:19 PM, Lan Tianyu wrote:
>> On 2016年05月26日 19:35, Andrew Cooper wrote:
>>> On 26/05/16 09:29, Lan Tianyu wrote:
>>>
>>> To be viable going forwards, any solution must work with PVH/HVMLite as
>>> much as HVM.  This alone negates qemu as a viable option.
>>>
>>> From a design point of view, having Xen needing to delegate to qemu to
>>> inject an interrupt into a guest seems backwards.
>>>
>>
>> Sorry, I am not familiar with HVMlite. HVMlite doesn't use Qemu and
>> the qemu virtual iommu can't work for it. We have to rewrite virtual
>> iommu in the Xen, right?
>>
>>>
>>> A whole lot of this would be easier to reason about if/when we get a
>>> basic root port implementation in Xen, which is necessary for HVMLite,
>>> and which will make the interaction with qemu rather more clean.  It is
>>> probably worth coordinating work in this area.
>>
>> The virtual iommu also should be under basic root port in Xen, right?
>>
>>>
>>> As for the individual issue of 288vcpu support, there are already
>>> issues
>>> with 64vcpu guests at the moment. While it is certainly fine to remove
>>> the hard limit at 255 vcpus, there is a lot of other work required to
>>> even get 128vcpu guests stable.
>>
>>
>> Could you give some points to these issues? We are enabling more vcpus
>> support and it can boot up 255 vcpus without IR support basically. It's
>> very helpful to learn about known issues.
>>
>> We will also add more tests for 128 vcpus into our regular test to find
>> related bugs. Increasing max vcpu to 255 should be a good start.
>
> Hi Andrew:
> Could you give more inputs about issues with 64 vcpus and what needs to
> be done to make 128vcpu guest stable? We hope to do somethings to
> improve them.
>
> What's progress of PCI host bridge in Xen? From your opinion, we should
> do that first, right? Thanks.

Very sorry for the delay.

There are multiple interacting issues here.  On the one side, it would
be useful if we could have a central point of coordination on
PVH/HVMLite work.  Roger - as the person who last did HVMLite work,
would you mind organising that?

For the qemu/xen interaction, the current state is woeful and a tangled
mess.  I wish to ensure that we don't make any development decisions
which makes the situation worse.

In your case, the two motivations are quite different I would recommend
dealing with them independently.

IIRC, the issue with more than 255 cpus and interrupt remapping is that
you can only use x2apic mode with more than 255 cpus, and IOAPIC RTEs
can't be programmed to generate x2apic interrupts?  In principle, if you
don't have an IOAPIC, are there any other issues to be considered?  What
happens if you configure the LAPICs in x2apic mode, but have the IOAPIC
deliver xapic interrupts?

On the other side of things, what is IGD passthrough going to look like
in Skylake?  Is there any device-model interaction required (i.e. the
opregion), or will it work as a completely standalone device?  What are
your plans with the interaction of virtual graphics and shared virtual
memory?

~Andrew

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


Re: [Xen-devel] [[PATCH v2 2/2] libxl: replace deprecated readdir_r() with readdir()

2016-06-02 Thread Chris Patterson
On Thu, Jun 2, 2016 at 12:13 PM, Ian Jackson  wrote:
> Chris Patterson writes ("Re: [[PATCH v2 2/2] libxl: replace deprecated 
> readdir_r() with readdir()"):
>> You're right, it should check for the error afterwards.
>>
>> How about something along the lines of:
>>
>> int saved_errno = errno;
>> errno = 0;
>> while ((de = readdir(dir)) != NULL) {
>> ...
>
> Wrong because you need to set errno=0 before each call to readdir.
> I really think you should abandon your efforts to keep the readdir
> call inside the while() condition :-).
>

I agree.  How does something like this look?

-int r = readdir_r(dir, de_buf, );
-
-if (r) {
+   errno = 0;
+   de = readdir(dir);
+
+   if (!de && errno) {

And I'll apply the same construct for tools/libfsimage/common/fsimage_plugin.c.

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


[Xen-devel] [xen-unstable-smoke test] 95204: tolerable all pass - PUSHED

2016-06-02 Thread osstest service owner
flight 95204 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95204/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  91fbfc37f5421bb2c5b08902a4a0bb4d1f8dc6ba
baseline version:
 xen  181677977fc35ddb848ae4d440fbb72e8afc8a1e

Last test of basis95193  2016-06-02 12:02:04 Z0 days
Testing same since95204  2016-06-02 16:02:12 Z0 days1 attempts


People who touched revisions under test:
  Ian Jackson 

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



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=91fbfc37f5421bb2c5b08902a4a0bb4d1f8dc6ba
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
91fbfc37f5421bb2c5b08902a4a0bb4d1f8dc6ba
+ branch=xen-unstable-smoke
+ revision=91fbfc37f5421bb2c5b08902a4a0bb4d1f8dc6ba
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.6-testing
+ '[' x91fbfc37f5421bb2c5b08902a4a0bb4d1f8dc6ba = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/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.xen.org:/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://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo 

Re: [Xen-devel] Unable to boot Xen 4.7-rc4 on HiKey

2016-06-02 Thread Tamas K Lengyel
On Thu, Jun 2, 2016 at 12:06 PM, Julien Grall  wrote:
> Hi Tamas,
>
> On 02/06/16 18:20, Tamas K Lengyel wrote:
>>
>> On Thu, Jun 2, 2016 at 11:14 AM, Tamas K Lengyel
>>  wrote:
>>>
>>> On Thu, Jun 2, 2016 at 11:02 AM, Julien Grall 
>>> wrote:
>>
>> Xen 4.7.0-rc (c/s Mon May 23 12:07:20 2016 +0100 git:8478c94-dirty) EFI
>> loader
>> Using configuration file 'xen.cfg'
>> hi6220-hikey.dtb: 0x7acaf000-0x7acba6e0
>> Image: 0x79fb9000-0x7aca1c00
>>   Xen 4.7.0-rc
>> (XEN) Xen version 4.7.0-rc (root@lan) (aarch64-linux-gnu-gcc
>> (Ubuntu/Linaro 5.3.1-14ubuntu2) 5.3.1 20160413) debug=n Wed Jun  1
>> 03:22:25 UTC 2016
>> (XEN) Latest ChangeSet: Mon May 23 12:07:20 2016 +0100 git:8478c94-dirty
>
>
> The tree seems to be dirty, what changes have you made into Xen?
>
> [...]
>
>> (XEN) Hypervisor Trap. HSR=0x9606 EC=0x25 IL=1 Syndrome=0x6
>> (XEN) CPU0: Unexpected Trap: Hypervisor
>> (XEN) [ Xen-4.7.0-rc  arm64  debug=n  Not tainted ]
>> (XEN) CPU:0
>> (XEN) PC: 00246494 xenmem_add_to_physmap_one+0x100/0x4e4
>
>
> Hmmm... have seen a such error yesterday on one of my platform and was not
> able to reproduce afterward :/.
>
> IIRC the PC was pointing to arch/arm/mm.c:1098. Can you confirm it is the
> same for you? You can use addr2line here.
>
> Can you reproduce it reliably? If so, could you provide your xen config,
> linux config, linux tree you are using?

I've recompiled Xen since with debug=y and the crash went away.. I'll
see if I can still reproduce it. Now that Xen is not crashing dom0
still did. I had to disable everything in the kernel related to
USB_DWC2 and recompile it, and finally everything boots!

Tamas

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


Re: [Xen-devel] Unable to boot Xen 4.7-rc4 on HiKey

2016-06-02 Thread Julien Grall

Hi Tamas,

On 02/06/16 18:20, Tamas K Lengyel wrote:

On Thu, Jun 2, 2016 at 11:14 AM, Tamas K Lengyel
 wrote:

On Thu, Jun 2, 2016 at 11:02 AM, Julien Grall  wrote:

Xen 4.7.0-rc (c/s Mon May 23 12:07:20 2016 +0100 git:8478c94-dirty) EFI loader
Using configuration file 'xen.cfg'
hi6220-hikey.dtb: 0x7acaf000-0x7acba6e0
Image: 0x79fb9000-0x7aca1c00
  Xen 4.7.0-rc
(XEN) Xen version 4.7.0-rc (root@lan) (aarch64-linux-gnu-gcc
(Ubuntu/Linaro 5.3.1-14ubuntu2) 5.3.1 20160413) debug=n Wed Jun  1
03:22:25 UTC 2016
(XEN) Latest ChangeSet: Mon May 23 12:07:20 2016 +0100 git:8478c94-dirty


The tree seems to be dirty, what changes have you made into Xen?

[...]


(XEN) Hypervisor Trap. HSR=0x9606 EC=0x25 IL=1 Syndrome=0x6
(XEN) CPU0: Unexpected Trap: Hypervisor
(XEN) [ Xen-4.7.0-rc  arm64  debug=n  Not tainted ]
(XEN) CPU:0
(XEN) PC: 00246494 xenmem_add_to_physmap_one+0x100/0x4e4


Hmmm... have seen a such error yesterday on one of my platform and was 
not able to reproduce afterward :/.


IIRC the PC was pointing to arch/arm/mm.c:1098. Can you confirm it is 
the same for you? You can use addr2line here.


Can you reproduce it reliably? If so, could you provide your xen config, 
linux config, linux tree you are using?


Regards,

--
Julien Grall

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


[Xen-devel] [ovmf test] 95178: regressions - FAIL

2016-06-02 Thread osstest service owner
flight 95178 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95178/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR. 
vs. 94748
 test-amd64-amd64-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail 
REGR. vs. 94748

version targeted for testing:
 ovmf 190895683aea889336367ea2ae4371abe9a87a19
baseline version:
 ovmf dc99315b8732b6e3032d01319d3f534d440b43d0

Last test of basis94748  2016-05-24 22:43:25 Z8 days
Failing since 94750  2016-05-25 03:43:08 Z8 days   24 attempts
Testing same since95178  2016-06-01 23:51:04 Z0 days1 attempts


People who touched revisions under test:
  Cohen, Eugene 
  Dandan Bi 
  Darbin Reyes 
  Eugene Cohen 
  Fu Siyuan 
  Fu, Siyuan 
  Gary Lin 
  Giri P Mudusuru 
  Hao Wu 
  Jeff Fan 
  Jiaxin Wu 
  Katie Dellaquila 
  Laszlo Ersek 
  Liming Gao 
  Marvin H?user 
  Marvin Haeuser 
  Maurice Ma 
  Michael Zimmermann 
  Star Zeng 
  Yonghong Zhu 

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



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

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

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

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


Not pushing.

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

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


[Xen-devel] [qemu-upstream-4.3-testing test] 95189: trouble: blocked/broken

2016-06-02 Thread osstest service owner
flight 95189 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95189/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   3 host-install(3) broken REGR. vs. 80927
 build-i386-pvops  3 host-install(3) broken REGR. vs. 80927
 build-i3863 host-install(3) broken REGR. vs. 80927
 build-amd64-pvops 3 host-install(3) broken REGR. vs. 80927

Tests which did not succeed, but are not blocking:
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-pv1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-pv   1 build-check(1)   blocked  n/a

version targeted for testing:
 qemuuc97c20f71240a538a19cb6b0e598bc1bbd5168f1
baseline version:
 qemuu10c1b763c26feb645627a1639e722515f3e1e876

Last test of basis80927  2016-02-06 13:30:02 Z  117 days
Testing same since93977  2016-05-10 11:09:16 Z   23 days   99 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Stefano Stabellini 

jobs:
 build-amd64  broken  
 build-i386   broken  
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-xl  blocked 
 test-amd64-i386-xl   blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd   blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked 
 test-amd64-i386-freebsd10-amd64  blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64 blocked 
 test-amd64-i386-xl-qemuu-win7-amd64  blocked 
 test-amd64-amd64-xl-credit2  blocked 
 test-amd64-i386-freebsd10-i386   blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel blocked 
 test-amd64-amd64-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-xl-multivcpublocked 
 

Re: [Xen-devel] Unable to boot Xen 4.7-rc4 on HiKey

2016-06-02 Thread Tamas K Lengyel
On Thu, Jun 2, 2016 at 11:14 AM, Tamas K Lengyel
 wrote:
> On Thu, Jun 2, 2016 at 11:02 AM, Julien Grall  wrote:
>>
>>
>> On 02/06/16 17:53, Tamas K Lengyel wrote:
>>>
>>> On Thu, Jun 2, 2016 at 4:34 PM, Chenxiao Zhao 
>>> wrote:



 On 6/1/2016 6:09 PM, Tamas K Lengyel wrote:
>
>
> On Wed, Jun 1, 2016 at 3:49 PM, Julien Grall 
> wrote:
>>
>>
>> On 01/06/2016 18:10, Tamas K Lengyel wrote:
>>>
>>>
>>>
>>> Hi all,
>>
>>
>>
>>
>> Hi Tamas,
>>
>>> following the steps from http://wiki.xen.org/wiki/HiKey I'm unable to
>>> get the board to boot Xen. I'm using the Debian reference image from
>>> linaro as base
>>> (https://builds.96boards.org/releases/hikey/linaro/debian/latest/)
>>> and that boots fine both from the SD card directly and through
>>> startup.nsh. However, when I try to boot Xen I see only the following:
>>>
>>> Xen 4.7.0-rc (c/s Mon May 23 12:07:20 2016 +0100 git:8478c94-dirty)
>>> EFI
>>> loader
>>> Using configuration file 'xen.cfg'
>>> Image: 0x7a121000-0x7acb8a70
>>>
>>> After that no output and dom0 never comes online on the network
>>> either. I tried compiling Xen on the device itself in case it was a
>>> problem with my cross-compile setup but no difference. Also with and
>>> without debug=y. Any tips on what might be going wrong here?
>>
>>
>>
>>
>> I gave a quick look at the upstream device-tree of the hikey, the path
>> /smb/uart@f7113000.
>>
>> If you use the upstream device-tree, it should be able to find the
>> correct
>> UART via "stdout-path" and therefore dtuart=... should not be
>> necessary.
>>
>> Let me know if it works for you, and I will update the wiki page.
>
>
>
> No, I removed the dtuart=... part from xen.cfg but there is no
> difference in the output and dom0 never comes up on the network
> either.



 Hi Tamas,

 My xen.cfg for Hikey is like this:

 options=dom0_mem=1024M dom0_max_vcpus=8 conswitch=x console=dtuart
 dtuart=/smb/uart@f7113000
 kernel=Image console=hvc root=/dev/mmcblk0p9 rootwait rw 3
 dtb=hi6220-hikey.dtb

 hope this could help you.
>>>
>>>
>>> Ah, thank you! Yes, the fact that the dtb goes in a third line in the
>>> cfg was missing! Should be put on wiki! I finally see Xen booting but
>>> dom0 still doesn't start.
>>
>>
>> Well, the firmware should provide a valid device-tree, and therefore
>> "dtb=..." should not be necessary.
>>
>> The way forward is too check why the UEFI firmware does not provide a Device
>> Tree (or maybe the DT path to the UART is different).
>>
>
> The UEFI firmware is the stock one that came with it.
>

So the stock kernel from the debian image doesn't boot with Xen and
produces no output. Having it up for a couple minutes made the board
quite hot as well. With the 4.1 kernel and associated dtb suggested on
the Wiki I get the following crash:

Xen 4.7.0-rc (c/s Mon May 23 12:07:20 2016 +0100 git:8478c94-dirty) EFI loader
Using configuration file 'xen.cfg'
hi6220-hikey.dtb: 0x7acaf000-0x7acba6e0
Image: 0x79fb9000-0x7aca1c00
 Xen 4.7.0-rc
(XEN) Xen version 4.7.0-rc (root@lan) (aarch64-linux-gnu-gcc
(Ubuntu/Linaro 5.3.1-14ubuntu2) 5.3.1 20160413) debug=n Wed Jun  1
03:22:25 UTC 2016
(XEN) Latest ChangeSet: Mon May 23 12:07:20 2016 +0100 git:8478c94-dirty
(XEN) Processor: 410fd033: "ARM Limited", variant: 0x0, part 0xd03, rev 0x3
(XEN) 64-bit Execution:
(XEN)   Processor Features:  
(XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32
(XEN) Extensions: FloatingPoint AdvancedSIMD
(XEN)   Debug Features: 10305106 
(XEN)   Auxiliary Features:  
(XEN)   Memory Model Features: 1122 
(XEN)   ISA Features:  00011120 
(XEN) 32-bit Execution:
(XEN)   Processor Features: 0131:00011011
(XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle
(XEN) Extensions: GenericTimer Security
(XEN)   Debug Features: 03010066
(XEN)   Auxiliary Features: 
(XEN)   Memory Model Features: 10101105 4000 0126 02102211
(XEN)  ISA Features: 02101110 13112111 21232042 01112131 00011142 00011121
(XEN) Using PSCI-1.0 for SMP bringup
(XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 1200 KHz
(XEN) GICv2 initialization:
(XEN) gic_dist_addr=f6801000
(XEN) gic_cpu_addr=f6802000
(XEN) gic_hyp_addr=f6804000
(XEN) gic_vcpu_addr=f6806000
(XEN) gic_maintenance_irq=25
(XEN) GICv2: 160 lines, 8 cpus, secure (IID 0200143b).
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Allocated console 

Re: [Xen-devel] [PATCH RFC 06/20] acpi/hvmloader: Collect processor and NUMA info in hvmloader

2016-06-02 Thread Boris Ostrovsky
On 06/02/2016 10:05 AM, Jan Beulich wrote:
 On 06.04.16 at 03:25,  wrote:
>> @@ -485,6 +494,10 @@ struct acpi_config {
>>  unsigned long acpi_pt_addr;
>>  uint32_t acpi_pt_length;
>>  } pt;
>> +uint32_t nr_vcpus;
>> +uint8_t  *vcpu_online;
>> +int apic_mode;
> Instead of copying those fields, how about simply adding a pointer
> to struct hvm_info_table here?
>
>> +struct acpi_numa numa;
> Same for this one - perhaps better a pointer, and an instance of the
> structure could then replace all those individual global variables.
>
>> @@ -910,6 +911,16 @@ void hvmloader_acpi_build_tables(struct acpi_config 
>> *config,
>>  if ( !strncmp(xenstore_read("platform/acpi_s4", "1"), "1", 1)  )
>>  config->table_flags |= ACPI_BUILD_SSDT_S4;
>>  
>> +config->nr_vcpus = hvm_info->nr_vcpus;
>> +config->vcpu_online = hvm_info->vcpu_online;
>> +config->apic_mode = 1;
> Why is this a hard coded 1? It was hvm_info->apic_mode before.

I think that's because hvm_info is initialized in libxl very late, after
ACPI is already set. Let me see whether there was a reason for this
order and if there wasn't then yes, I can point to hvm_info.

-boris


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


Re: [Xen-devel] Unable to boot Xen 4.7-rc4 on HiKey

2016-06-02 Thread Tamas K Lengyel
On Thu, Jun 2, 2016 at 11:02 AM, Julien Grall  wrote:
>
>
> On 02/06/16 17:53, Tamas K Lengyel wrote:
>>
>> On Thu, Jun 2, 2016 at 4:34 PM, Chenxiao Zhao 
>> wrote:
>>>
>>>
>>>
>>> On 6/1/2016 6:09 PM, Tamas K Lengyel wrote:


 On Wed, Jun 1, 2016 at 3:49 PM, Julien Grall 
 wrote:
>
>
> On 01/06/2016 18:10, Tamas K Lengyel wrote:
>>
>>
>>
>> Hi all,
>
>
>
>
> Hi Tamas,
>
>> following the steps from http://wiki.xen.org/wiki/HiKey I'm unable to
>> get the board to boot Xen. I'm using the Debian reference image from
>> linaro as base
>> (https://builds.96boards.org/releases/hikey/linaro/debian/latest/)
>> and that boots fine both from the SD card directly and through
>> startup.nsh. However, when I try to boot Xen I see only the following:
>>
>> Xen 4.7.0-rc (c/s Mon May 23 12:07:20 2016 +0100 git:8478c94-dirty)
>> EFI
>> loader
>> Using configuration file 'xen.cfg'
>> Image: 0x7a121000-0x7acb8a70
>>
>> After that no output and dom0 never comes online on the network
>> either. I tried compiling Xen on the device itself in case it was a
>> problem with my cross-compile setup but no difference. Also with and
>> without debug=y. Any tips on what might be going wrong here?
>
>
>
>
> I gave a quick look at the upstream device-tree of the hikey, the path
> /smb/uart@f7113000.
>
> If you use the upstream device-tree, it should be able to find the
> correct
> UART via "stdout-path" and therefore dtuart=... should not be
> necessary.
>
> Let me know if it works for you, and I will update the wiki page.



 No, I removed the dtuart=... part from xen.cfg but there is no
 difference in the output and dom0 never comes up on the network
 either.
>>>
>>>
>>>
>>> Hi Tamas,
>>>
>>> My xen.cfg for Hikey is like this:
>>>
>>> options=dom0_mem=1024M dom0_max_vcpus=8 conswitch=x console=dtuart
>>> dtuart=/smb/uart@f7113000
>>> kernel=Image console=hvc root=/dev/mmcblk0p9 rootwait rw 3
>>> dtb=hi6220-hikey.dtb
>>>
>>> hope this could help you.
>>
>>
>> Ah, thank you! Yes, the fact that the dtb goes in a third line in the
>> cfg was missing! Should be put on wiki! I finally see Xen booting but
>> dom0 still doesn't start.
>
>
> Well, the firmware should provide a valid device-tree, and therefore
> "dtb=..." should not be necessary.
>
> The way forward is too check why the UEFI firmware does not provide a Device
> Tree (or maybe the DT path to the UART is different).
>

The UEFI firmware is the stock one that came with it.

Tamas

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


Re: [Xen-devel] request backport for xen-4.6.2: qemu-xen-traditional.git; a=commit; h=df553c056104e3 (GNUTLS)

2016-06-02 Thread Ian Jackson
Mark Pryor writes ("request backport for xen-4.6.2: 
qemu-xen-traditional.git;a=commit;h=df553c056104e3 (GNUTLS)"):
> Backport below please:
> commitdf553c056104e3dd8a2bd2e72539a57c4c085bae
> Fix build with newer version of GNUTLS
> 
> this patch is only tagged for unstable now. Its needed also in the imminent
> 4.6.2.
> Anyone building xen in Xenial or Fc24 with latest gcc will require it.
> 
> I'm tried it against the 4.6.1 tarball and it applied.

Noted, thanks.

Ian.

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


Re: [Xen-devel] [PATCH for-4.7] x86/cpuid: Calculate a guests xfeature_mask from its featureset

2016-06-02 Thread Wei Liu
On Thu, Jun 02, 2016 at 05:48:01PM +0100, Andrew Cooper wrote:
> libxc current performs the xstate calculation for guests, and provides the
> information to Xen to be used when satisfying CPUID traps.  (There is further
> work planned to improve this arrangement, but the worst a buggy toolstack can
> do is make junk appear in the cpuid leaves for the guest.)
> 
> dom0 however has no policy constructed for it, and certain fields filter
> straight through from hardware.
> 
> Linux queries CPUID.7[0].{EAX/EDX} alone to choose a setting for %xcr0, which
> is action to take.  However, features such as MPX and PKRU are not supported
> for PV guests.  As a result, Linux, using leaked hardware information, fails
> to set %xcr0 on newer Skylake hardware with PKRU support, and crashes.
> 
> As an interim solution, dynamically calculate the correct xfeature_mask and
> xstate_size to report to the guest for CPUID.7[0] queries.  This ensures that
> domains don't see leaked hardware values, even when no cpuid policy is
> provided.
> 
> Similarly, CPUID.7[1]{ECX/EDX} represents the applicable settings for
> MSR_XSS.  Xen doesn't support any XSS states in guests, unconditionally clear
> them for HVM guests.
> 
> Reported-by: Luwei Kang 
> Signed-off-by: Andrew Cooper 
> ---
> CC: Jan Beulich 
> CC: Wei Liu 
> CC: Luwei Kang 
> CC: Huaitong Han 

Luwei and Huaitong, I would appreciate your test report on this patch.
Thanks!

If we can a tested-by tomorrow, we might be able to just apply this
patch for 4.7 (also subject to Jan's review / ack).

Wei.

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


Re: [Xen-devel] Unable to boot Xen 4.7-rc4 on HiKey

2016-06-02 Thread Julien Grall



On 02/06/16 17:53, Tamas K Lengyel wrote:

On Thu, Jun 2, 2016 at 4:34 PM, Chenxiao Zhao  wrote:



On 6/1/2016 6:09 PM, Tamas K Lengyel wrote:


On Wed, Jun 1, 2016 at 3:49 PM, Julien Grall  wrote:


On 01/06/2016 18:10, Tamas K Lengyel wrote:



Hi all,




Hi Tamas,


following the steps from http://wiki.xen.org/wiki/HiKey I'm unable to
get the board to boot Xen. I'm using the Debian reference image from
linaro as base
(https://builds.96boards.org/releases/hikey/linaro/debian/latest/)
and that boots fine both from the SD card directly and through
startup.nsh. However, when I try to boot Xen I see only the following:

Xen 4.7.0-rc (c/s Mon May 23 12:07:20 2016 +0100 git:8478c94-dirty) EFI
loader
Using configuration file 'xen.cfg'
Image: 0x7a121000-0x7acb8a70

After that no output and dom0 never comes online on the network
either. I tried compiling Xen on the device itself in case it was a
problem with my cross-compile setup but no difference. Also with and
without debug=y. Any tips on what might be going wrong here?




I gave a quick look at the upstream device-tree of the hikey, the path
/smb/uart@f7113000.

If you use the upstream device-tree, it should be able to find the
correct
UART via "stdout-path" and therefore dtuart=... should not be necessary.

Let me know if it works for you, and I will update the wiki page.



No, I removed the dtuart=... part from xen.cfg but there is no
difference in the output and dom0 never comes up on the network
either.



Hi Tamas,

My xen.cfg for Hikey is like this:

options=dom0_mem=1024M dom0_max_vcpus=8 conswitch=x console=dtuart
dtuart=/smb/uart@f7113000
kernel=Image console=hvc root=/dev/mmcblk0p9 rootwait rw 3
dtb=hi6220-hikey.dtb

hope this could help you.


Ah, thank you! Yes, the fact that the dtb goes in a third line in the
cfg was missing! Should be put on wiki! I finally see Xen booting but
dom0 still doesn't start.


Well, the firmware should provide a valid device-tree, and therefore 
"dtb=..." should not be necessary.


The way forward is too check why the UEFI firmware does not provide a 
Device Tree (or maybe the DT path to the UART is different).


Regards,

--
Julien Grall

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


Re: [Xen-devel] [PATCH RFC 03/20] acpi/hvmloader: Initialize vm_gid data outside ACPI code

2016-06-02 Thread Boris Ostrovsky
On 06/02/2016 09:03 AM, Jan Beulich wrote:
 On 06.04.16 at 03:25,  wrote:
>> --- a/tools/firmware/hvmloader/acpi/build.c
>> +++ b/tools/firmware/hvmloader/acpi/build.c
>> @@ -448,32 +448,24 @@ static int construct_secondary_tables(unsigned long 
>> *table_ptrs,
>>   *
>>   * Return 0 if memory failure, != 0 if success
>>   */
>> -static int new_vm_gid(struct acpi_info *acpi_info)
>> +static int new_vm_gid(struct acpi_config *config)
>>  {
>> -uint64_t vm_gid[2], *buf;
>> -const char * s;
>> -char *end;
>> -
>> -acpi_info->vm_gid_addr = 0;
>> -
>> -/* read ID and check for 0 */
>> -s = xenstore_read("platform/generation-id", "0:0");
>> -vm_gid[0] = strtoll(s, , 0);
>> -vm_gid[1] = 0;
>> -if ( end && end[0] == ':' )
>> -vm_gid[1] = strtoll(end+1, NULL, 0);
>> -if ( !vm_gid[0] && !vm_gid[1] )
>> +uint64_t *buf;
>> +
>> +config->acpi_info.vm_gid_addr = 0;
>> +
>> +/* check for 0 ID*/
>> +if ( !config->vm_gid[0] && !config->vm_gid[1] )
>>  return 1;
>>  
>>  /* copy to allocate BIOS memory */
>> -buf = (uint64_t *) mem_alloc(sizeof(vm_gid), 8);
>> +buf = (uint64_t *) mem_alloc(sizeof(config->vm_gid), 8);
>>  if ( !buf )
>>  return 0;
>> -memcpy(buf, vm_gid, sizeof(vm_gid));
>> +memcpy(buf, config->vm_gid, sizeof(config->vm_gid));
>>  
>>  /* set into ACPI table and HVM param the address */
>> -acpi_info->vm_gid_addr = virt_to_phys(buf);
>> -hvm_param_set(HVM_PARAM_VM_GENERATION_ID_ADDR, acpi_info->vm_gid_addr);
>> +config->acpi_info.vm_gid_addr = virt_to_phys(buf);
> Here things get interesting: If different entities are responsible for
> filling different parts of acpi_info, I think this should be documented
> in the structure definition.

There are IN and OUT parameters in acpi_info, and this is not
documented. It should be.

>  Can't this be left to the entity initializing
> that structure?

vm_gid_addr is calculated by (what will be) libacpi, it's an OUT parameter.


-boris




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


Re: [Xen-devel] Unable to boot Xen 4.7-rc4 on HiKey

2016-06-02 Thread Tamas K Lengyel
On Thu, Jun 2, 2016 at 4:34 PM, Chenxiao Zhao  wrote:
>
>
> On 6/1/2016 6:09 PM, Tamas K Lengyel wrote:
>>
>> On Wed, Jun 1, 2016 at 3:49 PM, Julien Grall  wrote:
>>>
>>> On 01/06/2016 18:10, Tamas K Lengyel wrote:


 Hi all,
>>>
>>>
>>>
>>> Hi Tamas,
>>>
 following the steps from http://wiki.xen.org/wiki/HiKey I'm unable to
 get the board to boot Xen. I'm using the Debian reference image from
 linaro as base
 (https://builds.96boards.org/releases/hikey/linaro/debian/latest/)
 and that boots fine both from the SD card directly and through
 startup.nsh. However, when I try to boot Xen I see only the following:

 Xen 4.7.0-rc (c/s Mon May 23 12:07:20 2016 +0100 git:8478c94-dirty) EFI
 loader
 Using configuration file 'xen.cfg'
 Image: 0x7a121000-0x7acb8a70

 After that no output and dom0 never comes online on the network
 either. I tried compiling Xen on the device itself in case it was a
 problem with my cross-compile setup but no difference. Also with and
 without debug=y. Any tips on what might be going wrong here?
>>>
>>>
>>>
>>> I gave a quick look at the upstream device-tree of the hikey, the path
>>> /smb/uart@f7113000.
>>>
>>> If you use the upstream device-tree, it should be able to find the
>>> correct
>>> UART via "stdout-path" and therefore dtuart=... should not be necessary.
>>>
>>> Let me know if it works for you, and I will update the wiki page.
>>
>>
>> No, I removed the dtuart=... part from xen.cfg but there is no
>> difference in the output and dom0 never comes up on the network
>> either.
>
>
> Hi Tamas,
>
> My xen.cfg for Hikey is like this:
>
> options=dom0_mem=1024M dom0_max_vcpus=8 conswitch=x console=dtuart
> dtuart=/smb/uart@f7113000
> kernel=Image console=hvc root=/dev/mmcblk0p9 rootwait rw 3
> dtb=hi6220-hikey.dtb
>
> hope this could help you.

Ah, thank you! Yes, the fact that the dtb goes in a third line in the
cfg was missing! Should be put on wiki! I finally see Xen booting but
dom0 still doesn't start.

Tamas

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


Re: [Xen-devel] Unable to boot Xen 4.7-rc4 on HiKey

2016-06-02 Thread Tamas K Lengyel
On Wed, Jun 1, 2016 at 3:49 PM, Julien Grall  wrote:
> On 01/06/2016 18:10, Tamas K Lengyel wrote:
>>
>> Hi all,
>
>
> Hi Tamas,
>
>> following the steps from http://wiki.xen.org/wiki/HiKey I'm unable to
>> get the board to boot Xen. I'm using the Debian reference image from
>> linaro as base
>> (https://builds.96boards.org/releases/hikey/linaro/debian/latest/)
>> and that boots fine both from the SD card directly and through
>> startup.nsh. However, when I try to boot Xen I see only the following:
>>
>> Xen 4.7.0-rc (c/s Mon May 23 12:07:20 2016 +0100 git:8478c94-dirty) EFI
>> loader
>> Using configuration file 'xen.cfg'
>> Image: 0x7a121000-0x7acb8a70
>>
>> After that no output and dom0 never comes online on the network
>> either. I tried compiling Xen on the device itself in case it was a
>> problem with my cross-compile setup but no difference. Also with and
>> without debug=y. Any tips on what might be going wrong here?
>
>
> I gave a quick look at the upstream device-tree of the hikey, the path
> /smb/uart@f7113000.
>
> If you use the upstream device-tree, it should be able to find the correct
> UART via "stdout-path" and therefore dtuart=... should not be necessary.
>
> Let me know if it works for you, and I will update the wiki page.

It doesn't unfortunately, without specifying dtuart=... I still see no
Xen output.

Tamas

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


Re: [Xen-devel] [PATCH RFC 02/20] acpi/hvmloader: Move acpi_info initialization out of ACPI code

2016-06-02 Thread Boris Ostrovsky
On 06/02/2016 08:54 AM, Jan Beulich wrote:
 On 06.04.16 at 03:25,  wrote:
>> acpi_info can be initialized by hvmloader itself. Now ACPI code
>> doesn't need to use hvmloader-private variables/routines such as
>> uart_exists(), lpt_exists() etc.
> So from a mechanical pov the patch looks fine (one remark below),
> but if you move this out from acpi/, who's going to do the setup of
> that structure outside of hvmloader? And if done by another
> entity, how do you mean things to remain in sync? 

Each caller (currently hvmloader and libxc, possibly the hypervisor in
the future) will initialize it. (I think you saw this in the next patch)

> And btw., you're
> still not fully decoupling things: ACPI_INFO_PHYSICAL_ADDRESS is
> a hvmloader thing, which you just move the reference to inside
> acpi/.

It's not an hvmloader thing, it's the ACPI thing: this is the address
that should match DSDT's description.

Perhaps I should have a script that extracts this address from dsdt.asl
and then make libacpi return it instead of hardcoding it in callers' code.

-boris

>
>> @@ -619,20 +597,12 @@ void acpi_build_tables(struct acpi_config *config, 
>> unsigned int physical)
>>   offsetof(struct acpi_20_rsdp, extended_checksum),
>>   sizeof(struct acpi_20_rsdp));
>>  
>> -if ( !new_vm_gid(acpi_info) )
>> +if ( !new_vm_gid(>acpi_info) )
>>  goto oom;
>>  
>> -acpi_info->com1_present = uart_exists(0x3f8);
>> -acpi_info->com2_present = uart_exists(0x2f8);
>> -acpi_info->lpt1_present = lpt_exists(0x378);
>> -acpi_info->hpet_present = hpet_exists(ACPI_HPET_ADDRESS);
>> -acpi_info->pci_min = pci_mem_start;
>> -acpi_info->pci_len = pci_mem_end - pci_mem_start;
>> -if ( pci_hi_mem_end > pci_hi_mem_start )
>> -{
>> -acpi_info->pci_hi_min = pci_hi_mem_start;
>> -acpi_info->pci_hi_len = pci_hi_mem_end - pci_hi_mem_start;
>> -}
>> +memcpy((struct acpi_info *)ACPI_INFO_PHYSICAL_ADDRESS,
>> +   >acpi_info,
>> +   sizeof(config->acpi_info));
> I'd prefer structure assignment to be used in cases like this, as
> that lets the compiler check that the types match.
>
> Jan
>



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


[Xen-devel] [PATCH for-4.7] x86/cpuid: Calculate a guests xfeature_mask from its featureset

2016-06-02 Thread Andrew Cooper
libxc current performs the xstate calculation for guests, and provides the
information to Xen to be used when satisfying CPUID traps.  (There is further
work planned to improve this arrangement, but the worst a buggy toolstack can
do is make junk appear in the cpuid leaves for the guest.)

dom0 however has no policy constructed for it, and certain fields filter
straight through from hardware.

Linux queries CPUID.7[0].{EAX/EDX} alone to choose a setting for %xcr0, which
is action to take.  However, features such as MPX and PKRU are not supported
for PV guests.  As a result, Linux, using leaked hardware information, fails
to set %xcr0 on newer Skylake hardware with PKRU support, and crashes.

As an interim solution, dynamically calculate the correct xfeature_mask and
xstate_size to report to the guest for CPUID.7[0] queries.  This ensures that
domains don't see leaked hardware values, even when no cpuid policy is
provided.

Similarly, CPUID.7[1]{ECX/EDX} represents the applicable settings for
MSR_XSS.  Xen doesn't support any XSS states in guests, unconditionally clear
them for HVM guests.

Reported-by: Luwei Kang 
Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Wei Liu 
CC: Luwei Kang 
CC: Huaitong Han 
---
 xen/arch/x86/hvm/hvm.c   | 53 ++--
 xen/arch/x86/traps.c | 50 -
 xen/arch/x86/xstate.c|  2 +-
 xen/include/asm-x86/xstate.h | 32 +-
 4 files changed, 114 insertions(+), 23 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index bb98051..72bbed5 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3362,7 +3362,7 @@ void hvm_cpuid(unsigned int input, unsigned int *eax, 
unsigned int *ebx,
 
 switch ( input )
 {
-unsigned int _ecx, _edx;
+unsigned int _ebx, _ecx, _edx;
 
 case 0x1:
 /* Fix up VLAPIC details. */
@@ -3443,6 +3443,51 @@ void hvm_cpuid(unsigned int input, unsigned int *eax, 
unsigned int *ebx,
 switch ( count )
 {
 case 0:
+{
+uint64_t xfeature_mask = XSTATE_FP_SSE;
+uint32_t xstate_size = XSTATE_AREA_MIN_SIZE;
+
+if ( _ecx & cpufeat_mask(X86_FEATURE_AVX) )
+{
+xfeature_mask |= XSTATE_YMM;
+xstate_size = MAX(xstate_size,
+  xstate_offsets[_XSTATE_YMM] +
+  xstate_sizes[_XSTATE_YMM]);
+}
+
+_ecx = 0;
+hvm_cpuid(7, NULL, &_ebx, &_ecx, NULL);
+
+if ( _ebx & cpufeat_mask(X86_FEATURE_MPX) )
+{
+xfeature_mask |= XSTATE_BNDREGS | XSTATE_BNDCSR;
+xstate_size = MAX(xstate_size,
+  xstate_offsets[_XSTATE_BNDCSR] +
+  xstate_sizes[_XSTATE_BNDCSR]);
+}
+
+if ( _ebx & cpufeat_mask(X86_FEATURE_PKU) )
+{
+xfeature_mask |= XSTATE_PKRU;
+xstate_size = MAX(xstate_size,
+  xstate_offsets[_XSTATE_PKRU] +
+  xstate_sizes[_XSTATE_PKRU]);
+}
+
+hvm_cpuid(0x8001, NULL, NULL, &_ecx, NULL);
+
+if ( _ecx & cpufeat_mask(X86_FEATURE_LWP) )
+{
+xfeature_mask |= XSTATE_LWP;
+xstate_size = MAX(xstate_size,
+  xstate_offsets[_XSTATE_LWP] +
+  xstate_sizes[_XSTATE_LWP]);
+}
+
+*eax = (uint32_t)xfeature_mask;
+*edx = (uint32_t)(xfeature_mask >> 32);
+*ecx = xstate_size;
+
 /*
  * Always read CPUID[0xD,0].EBX from hardware, rather than domain
  * policy.  It varies with enabled xstate, and the correct xcr0 is
@@ -3450,6 +3495,8 @@ void hvm_cpuid(unsigned int input, unsigned int *eax, 
unsigned int *ebx,
  */
 cpuid_count(input, count, , ebx, , );
 break;
+}
+
 case 1:
 *eax &= hvm_featureset[FEATURESET_Da1];
 
@@ -3463,7 +3510,9 @@ void hvm_cpuid(unsigned int input, unsigned int *eax, 
unsigned int *ebx,
 cpuid_count(input, count, , ebx, , );
 }
 else
-*ebx = *ecx = *edx = 0;
+*ebx = 0;
+
+*ecx = *edx = 0;
 break;
 }
 break;
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 5d7232d..a2688c3 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -928,7 +928,7 @@ void pv_cpuid(struct cpu_user_regs *regs)
 
 switch ( leaf )
 {
-uint32_t tmp;
+uint32_t tmp, _ecx;
 
 case 0x0001:

Re: [Xen-devel] [PATCH RFC 01/20] hvmloader: Provide hvmloader_acpi_build_tables()

2016-06-02 Thread Boris Ostrovsky
On 06/02/2016 08:42 AM, Jan Beulich wrote:
 On 06.04.16 at 03:25,  wrote:
>> @@ -856,6 +857,12 @@ int hpet_exists(unsigned long hpet_base)
>>  return ((hpet_id >> 16) == 0x8086);
>>  }
>>  
>> +void hvmloader_acpi_build_tables(struct acpi_config *config,
>> + unsigned int physical)
>> +{
>> +acpi_build_tables(config, physical);
>> +}
> I guess later patches will make clear why this is an improvement.
> On its own it doesn't look worthwhile.
>

This is really to make reviewing easier. Not an improvement of any kind.

-boris

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


Re: [Xen-devel] [PATCH RFC 00/20] Make ACPI builder available to components other than hvmloader

2016-06-02 Thread Boris Ostrovsky
On 06/02/2016 08:40 AM, Jan Beulich wrote:
 On 06.04.16 at 03:25,  wrote:
>> This is an RFC for making hvmloader's ACPI builder available to both the
>> toolstack and the hypervisor, as discussed in
>> http://lists.xenproject.org/archives/html/xen-devel/2016-02/msg01228.html 
>>
>> The series
>> * Removes dependency of today's builder on hvmloader interfaces
>> * Makes many of the tables built optionally.
>> * Moves tools/hvmloader/acpi directory to xen/common/libacpi
>> * Builds tables for PVHv2 domU guests in libxc
>>
>> There is still a number of questions about this implementation, thus it's
>> an RFC. Examples of things that need to be discussed are
>>
>> * ACPI tables are built for PVHv2 guests unconditionally. We probably want
>>   to make this an option.
>> * Not sure about header files, especially xen/common/libacpi/x86.h and 
>>   tools/firmware/hvmloader/{stdio.h,string.h} 
>> * The builder is compiled into the hypervisor even though currently
>>   there are no users (PVHv2 dom0 will be the one)
> Is that really what we want? I thought we don't really mean to
> build ACPI tables from scratch for Dom0, but rather follow ARM's
> customization approach.

You mean xen/arch/arm/domain_build.c:prepare_acpi()?

The thinking was that customization will be able to make use of this
library. Roger?


>  And if we don't want this, then the
> placement of this now shared code would need reconsidering.

Right. In fact I originally had this as tools/libacpi.

-boris


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


Re: [Xen-devel] [PATCH RFC 18/20] libxc/acpi: Build ACPI tables for HVMlite guests

2016-06-02 Thread Roger Pau Monné
Thanks for looking into this, I've found a couple of issues when compiling 
this with clang.

On Tue, Apr 05, 2016 at 09:25:47PM -0400, Boris Ostrovsky wrote:
> Signed-off-by: Boris Ostrovsky 
> ---
>  tools/libxc/Makefile  |  22 +++-
>  tools/libxc/include/xc_dom.h  |   1 +
>  tools/libxc/xc_acpi.c | 268 
> ++
>  tools/libxc/xc_dom_x86.c  |   7 +
>  tools/libxl/libxl_x86.c   |  19 +--
>  xen/common/libacpi/Makefile   |   5 +-
>  xen/common/libacpi/acpi2_0.h  |   2 +-
>  xen/common/libacpi/build.c|   2 +-
>  xen/common/libacpi/dsdt_empty.asl |  22 
>  9 files changed, 335 insertions(+), 13 deletions(-)
>  create mode 100644 tools/libxc/xc_acpi.c
>  create mode 100644 xen/common/libacpi/dsdt_empty.asl
> 
> diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
> index 608404f..9569e54 100644
> +++ b/tools/libxc/xc_acpi.c

Missing license header?

> @@ -0,0 +1,268 @@
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "xg_private.h"
> +#include "xc_dom.h"
> +#include "xenctrl.h"
> +
> +#include "acpi2_0.h"
> +
> +#define RESERVED_MEMORY_DYNAMIC_START 0xFC001000
> +#define ACPI_PHYSICAL_ADDRESS 0x000EA020
> +
> +/* Initial allocation for ACPI tables */
> +#define NUM_ACPI_PAGES  16
> +
> +#define PFN(paddr)  ((paddr) >> PAGE_SHIFT)
> +
> +extern unsigned char dsdt_anycpu[], dsdt_15cpu[], dsdt_empty[];
> +extern int dsdt_anycpu_len, dsdt_15cpu_len, dsdt_empty_len;
> +
> +static uint64_t alloc_up, alloc_down;
> +static unsigned long base_addr;
> +
> +/* Assumes contiguous physical space */
> +static unsigned long virt_to_phys(void *v)
> +{
> + return (((unsigned long)v - base_addr) + RESERVED_MEMORY_DYNAMIC_START);
> +}
> +
> +static void *mem_alloc(uint32_t size, uint32_t align)
> +{
> +uint64_t s, e;
> +
> +/* Align to at least 16 bytes. */
> +if ( align < 16 )
> +align = 16;
> +
> +s = (alloc_up + align) & ~((uint64_t)align - 1);
> +e = s + size - 1;
> +
> +/* TODO: Reallocate memory */
> +if ((e < s) || (e >= alloc_down)) return NULL;
> +
> +while ( PFN(alloc_up) != PFN(e) )
> +{
> +alloc_up += PAGE_SIZE;
> +}
> +
> +alloc_up = e;
> +
> +return (void *)(unsigned long)s;
> +}
> +
> +static int init_acpi_config(struct xc_dom_image *dom,
> +struct acpi_config *config)
> +{
> +xc_interface *xch = dom->xch;
> +uint32_t domid = dom->guest_domid;
> +xc_dominfo_t info;
> +int i, rc;
> +
> +memset(config, 0, sizeof(*config));
> +
> +config->dsdt_anycpu = config->dsdt_15cpu = dsdt_empty;
> +config->dsdt_anycpu_len = config->dsdt_15cpu_len = dsdt_empty_len;
> +
> +rc = xc_domain_getinfo(xch, domid, 1, );
> +if ( rc < 0 )
> +{
> +DOMPRINTF("%s: getdomaininfo failed (rc=%d)", __FUNCTION__, rc);
> +return rc;
> +}
> +
> +config->apic_mode = 1;
> +
> +if ( dom->nr_vnodes )
> +{
> +struct acpi_numa *numa = >numa;
> +
> +numa->vmemrange = calloc(dom->nr_vmemranges,
> + sizeof(*numa->vmemrange));
> +numa->vdistance = calloc(dom->nr_vnodes,
> + sizeof(*numa->vdistance));
> +numa->vcpu_to_vnode = calloc(config->nr_vcpus,
> + sizeof(*numa->vcpu_to_vnode));
> +if ( !numa->vmemrange || !numa->vdistance || !numa->vcpu_to_vnode )
> +{
> +DOMPRINTF("%s: Out of memory", __FUNCTION__);
> +free(numa->vmemrange);
> +free(numa->vdistance);
> +free(numa->vcpu_to_vnode);
> +return -ENOMEM;
> +}
> +
> +rc = xc_domain_getvnuma(xch, domid, >nr_vnodes,
> +>nr_vmemranges,
> +>nr_vcpus, numa->vmemrange,
> +numa->vdistance, numa->vcpu_to_vnode);
> +
> + if ( rc )
> +{
> +DOMPRINTF("%s: xc_domain_getvnuma failed (rc=%d)", __FUNCTION__, 
> rc);
> +return rc;
> +}
> +}
> +else
> +config->nr_vcpus = info.max_vcpu_id + 1;
> +
> +config->vcpu_online = calloc((HVM_MAX_VCPUS + 7) / 8,
> + sizeof(*config->vcpu_online));
> +if ( config->vcpu_online == NULL )
> +{
> +DOMPRINTF("%s: Can't allocate vcpu_online", __FUNCTION__);
> +return -ENOMEM;
> +}
> +
> +for (i=0; inr_vcpus; i++)
> +config->vcpu_online[i / 8] |= 1 << (i & 7);
> +
> +config->mem_ops.alloc = mem_alloc;
> +config->mem_ops.v2p = virt_to_phys;
> +
> +return 0;
> +}
> +
> +int xc_dom_build_acpi(struct xc_dom_image *dom)
> +{
> +struct acpi_config config;
> +uint32_t domid = dom->guest_domid;
> +xc_interface *xch = dom->xch;

Re: [Xen-devel] [[PATCH v2 2/2] libxl: replace deprecated readdir_r() with readdir()

2016-06-02 Thread Ian Jackson
Chris Patterson writes ("Re: [[PATCH v2 2/2] libxl: replace deprecated 
readdir_r() with readdir()"):
> You're right, it should check for the error afterwards.
> 
> How about something along the lines of:
> 
> int saved_errno = errno;
> errno = 0;
> while ((de = readdir(dir)) != NULL) {
> ...

Wrong because you need to set errno=0 before each call to readdir.
I really think you should abandon your efforts to keep the readdir
call inside the while() condition :-).

> if (errno) {
>LOGE(ERROR, "readdir failed: %s", strerror(errno));
>rc = ERROR_FAIL;
> }
> errno = saved_errno;

I haven't eyeballed the context in detail but I don't understand why
you think it necessary to save and restore errno.  All the many system
and library calls made throughout this code may overwrite it anyway.

Ian.

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


Re: [Xen-devel] xl migrate regression in staging

2016-06-02 Thread annie li


On 6/2/2016 11:21 AM, Wei Liu wrote:

On Thu, Jun 02, 2016 at 11:18:36AM -0400, annie li wrote:

On 4/14/2016 11:36 AM, Olaf Hering wrote:

On Thu, Apr 14, Wei Liu wrote:


Maybe go back to 96ae556569b8eaedc0bb242932842c3277b515d8 and try again?
Then 5cf46a66883ad7a56c5bdee97696373473f80974 and try? So that I can
know if it is related to COLO series. No, don't try to bisect that
because it's broken in the middle.

I think I took enough snapshots for my rpm packages to get close to the
above commits. It will take some time to cycle through them.



Also as Andrew suggested if you can reproduce it with a smaller domain
or share the guest image with us, that would be helpful.

I have already sent him the link.

Any update, guys?
I hit similar problem recently too.


Yes, this has been fixed in master branch.

See de28b189bd329dd20a245a318be8feea2c4cc60a.

Nice! tested with newer version with this patch, it works.

Thanks
Annie


Wei.


Thanks
Annie

___
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] [PATCH RFC 0/6] Set of PV drivers used by production project

2016-06-02 Thread Wei Liu
On Thu, May 19, 2016 at 05:37:29PM +0300, Iurii Mykhalskyi wrote:
> This patches introduce set of pv drivers interfaces.
> Drivers interfaces list:
>  - PV RTC - real-time clock
>  - PV TTY - interface for pv version for device controlled by
> via tty (e.g. GPS)
>  - PV Audio - sound interface virtualization
>  - PV DRM - direct rengering manager virtualization
>  - PV RPMSG - remove procedure call interface, in our case
> used for playback codecs virtualization
> 
> Iurii Mykhalskyi (2):
>   libxl: implementation of PV rtc device interface
>   libxl: implementation of PV tty device interface.
> 
> Pavlo Suikov (4):
>   libxl: implementation of PV audio device interface
>   libxl: implementation of PV event device interface
>   libxl: implementation of PV DRM device interface
>   libxl: implementation of PV RPMSG device interface
> 
>  tools/libxl/libxl.c  | 1781 
> +-
>  tools/libxl/libxl.h  |  102 ++
>  tools/libxl/libxl_create.c   |  214 +++-
>  tools/libxl/libxl_device.c   |   12 +
>  tools/libxl/libxl_internal.c |8 +
>  tools/libxl/libxl_internal.h |   88 +-
>  tools/libxl/libxl_types.idl  |  131 +++
>  tools/libxl/libxl_types_internal.idl |6 +
>  tools/libxl/libxl_utils.h|   19 +
>  tools/libxl/xl.h |   18 +
>  tools/libxl/xl_cmdimpl.c | 1035 +++-
>  tools/libxl/xl_cmdtable.c|   95 ++
>  12 files changed, 3499 insertions(+), 10 deletions(-)
> 

Just a heads-up, we have now reworked the xenstore paths libxl used to
handle devices (XSA-175 and XSA-180), you might want to update this
series.

I will still review this series as if the paths have been updated when I
get around to it. But if you manage to finish a new version, don't
hesitate to send it out.

Wei.

> -- 
> 2.8.2
> 

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


Re: [Xen-devel] [PATCH v3 13/16 - RFC] x86: add multiboot2 protocol support for EFI platforms

2016-06-02 Thread Daniel Kiper
On Thu, Jun 02, 2016 at 02:34:28AM -0600, Jan Beulich wrote:
> >>> On 01.06.16 at 21:03,  wrote:
> > On Fri, May 27, 2016 at 03:02:25AM -0600, Jan Beulich wrote:
> >> >>> On 25.05.16 at 23:02,  wrote:
> >> > On Wed, May 25, 2016 at 03:32:37AM -0600, Jan Beulich wrote:
> >> >> isn't going to be very helpful in the field, I'm afraid. Even more so
> >> >> that there's no guarantee for a UART to be at port 0x3f8. That's
> >> >
> >> > Right but we do not have big choice here at very early boot stage... 
> >> > :-(((
> >>
> >> Excuse me? You're running on EFI, so you have full infrastructure
> >> available to you. As much as in a normal BIOS scenario (and on a
> >> half way normal system) we can assume a text mode screen with
> >> video memory mapped at B8000, under EFI we can assume output
> >> capabilities (whichever the system owner set up in the firmware
> >> setup).
> >
> > Potentially we can do that for bad_cpu only. However, does it pays?
> > I suppose that most, if not all, platforms with UEFI have CPUs with
> > X86_FEATURE_LM.
>
> I'm not sure about that, keeping various Atoms in mind.

OK.

> > Sadly, It it not feasible for not_multiboot and mb2_too_old. Former
> > means that we were loaded by unknown boot loader and interface is
> > not defined.
>
> Hence we may at least assume accessing VGA memory won't do
> much bad.

Well, we are in black hole here but I am not sure that even in that
situation we should blindly poke VGA memory region. Especially on
EFI platforms behavior can be at least undefined.

> > Hence, we are not able to get anything from EFI. Latter
> > means that we were booted via older multiboot2 version which shutdown
> > boot services.
>
> Hmm, that's certainly one of the possibilities, yes. I wonder then
> whether we wouldn't better do away with all of those output
> attempts then.

This is one option. However, IMO, not nice. Maybe we should stay with
serial plus VGA on legacy BIOS platforms. Serials looks quite well
defined even on EFI platforms. However, if it is not available x86
out instruction should not do any harm. Though if we wish to increase
chance of reaching interested parties I would send error messages to
0x3f8 and 0x2f8 at once. AFAICT, on many machines usually at least one
if not both standard/legacy serial ports are available.

[...]

> >> >> > +/*
> >> >> > + * Multiboot2 information address is 32-bit,
> >> >> > + * so, zero higher half of %rbx.
> >> >> > + */
> >> >> > +mov %ebx,%ebx
> >> >>
> >> >> Wait, no - that's a protocol bug then. We're being entered in 64-bit
> >> >> mode here, so registers should be in 64-bit clean state.
> >> >
> >> > You mean higher half cleared. Right? This is not guaranteed.
> >>
> >> Hence me saying "that's a protocol bug then".
> >
> > Why? Protocol strictly says that "this is not guaranteed".
> > What is the problem with that? Potentially loader can set
> > %rbx higher half to e.g. 0 but I do not think it is needed.
>
> A 64-bit interface shouldn't specify values to live only in halves
> of registers, in my opinion. Remember that the architecture
> guarantees high halves to get zeroed for 32-bit writes to
> registers, so I don't even see any complication for the provider
> side of the interface (which necessarily runs in 64-bit mode).

OK, you convinced me. I will update GRUB2 patches.

> >> > Please check this:
> >> > http://lists.gnu.org/archive/html/grub-devel/2016-03/msg00304.html
> >>
> >> Other than the description of the patch I can't see anything like that,
> >> in particular
> >> - no occurrence of "ebx" in any of the added or changed code
> >> - MULTIBOOT_EFI_MBI_REGISTER getting #define-d as rbx
> >
> > Please check multiboot2 spec, section 3.2, Machine state. It is not
> > freshest one (I am working on EFI updates right now) but I hope that it,
> > together with patch comment, will shed some light.
>
> May I refer you back to you, in another patch, adding just two
> architecture defines for MB2: i386 and MIPS? That's a pretty
> clear indication that there can't be much consistency to be
> expected when talk comes to x86-64 (which most definitely is
> not i386).
>
> >> >> > @@ -170,12 +313,19 @@ multiboot2_proto:
> >> >> >  jne 1f
> >> >> >
> >> >> >  mov MB2_mem_lower(%ecx),%edx
> >> >> > -jmp trampoline_setup
> >> >> > +jmp trampoline_bios_setup
> >> >> >
> >> >> >  1:
> >> >> > +/* EFI mode is not supported via legacy BIOS path. */
> >> >> > +cmpl$MULTIBOOT2_TAG_TYPE_EFI32,MB2_tag_type(%ecx)
> >> >> > +je  mb2_too_old
> >> >> > +
> >> >> > +cmpl$MULTIBOOT2_TAG_TYPE_EFI64,MB2_tag_type(%ecx)
> >> >> > +je  mb2_too_old
> >> >>
> >> >> According to the comment we're on the legacy BIOS boot path
> >> >> here, yet at mb2_too_old you assume no text mode VGA. I.e. I'm
> >> >> now even confused about the output handling there.
> >> >

[Xen-devel] [RFC v3 04/45] arc: dma-mapping: Use unsigned long for dma_attrs

2016-06-02 Thread Krzysztof Kozlowski
Split out subsystem specific changes for easier reviews. This will be
squashed with main commit.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/arc/mm/dma.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arc/mm/dma.c b/arch/arc/mm/dma.c
index 73d7e4c75b7d..3d1f467d1792 100644
--- a/arch/arc/mm/dma.c
+++ b/arch/arc/mm/dma.c
@@ -22,7 +22,7 @@
 
 
 static void *arc_dma_alloc(struct device *dev, size_t size,
-   dma_addr_t *dma_handle, gfp_t gfp, struct dma_attrs *attrs)
+   dma_addr_t *dma_handle, gfp_t gfp, unsigned long attrs)
 {
unsigned long order = get_order(size);
struct page *page;
@@ -90,7 +90,7 @@ static void *arc_dma_alloc(struct device *dev, size_t size,
 }
 
 static void arc_dma_free(struct device *dev, size_t size, void *vaddr,
-   dma_addr_t dma_handle, struct dma_attrs *attrs)
+   dma_addr_t dma_handle, unsigned long attrs)
 {
struct page *page = virt_to_page(dma_handle);
int is_non_coh = 1;
@@ -129,7 +129,7 @@ static void _dma_cache_sync(phys_addr_t paddr, size_t size,
 
 static dma_addr_t arc_dma_map_page(struct device *dev, struct page *page,
unsigned long offset, size_t size, enum dma_data_direction dir,
-   struct dma_attrs *attrs)
+   unsigned long attrs)
 {
phys_addr_t paddr = page_to_phys(page) + offset;
_dma_cache_sync(paddr, size, dir);
@@ -137,7 +137,7 @@ static dma_addr_t arc_dma_map_page(struct device *dev, 
struct page *page,
 }
 
 static int arc_dma_map_sg(struct device *dev, struct scatterlist *sg,
-  int nents, enum dma_data_direction dir, struct dma_attrs *attrs)
+  int nents, enum dma_data_direction dir, unsigned long attrs)
 {
struct scatterlist *s;
int i;
-- 
1.9.1


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


[Xen-devel] [RFC v3 27/45] hexagon: dma-mapping: Use unsigned long for dma_attrs

2016-06-02 Thread Krzysztof Kozlowski
Split out subsystem specific changes for easier reviews. This will be
squashed with main commit.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/hexagon/include/asm/dma-mapping.h | 1 -
 arch/hexagon/kernel/dma.c  | 8 
 2 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/arch/hexagon/include/asm/dma-mapping.h 
b/arch/hexagon/include/asm/dma-mapping.h
index aa6203464520..7ef58df909fc 100644
--- a/arch/hexagon/include/asm/dma-mapping.h
+++ b/arch/hexagon/include/asm/dma-mapping.h
@@ -26,7 +26,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 struct device;
diff --git a/arch/hexagon/kernel/dma.c b/arch/hexagon/kernel/dma.c
index 9e3ddf792bd3..b9017785fb71 100644
--- a/arch/hexagon/kernel/dma.c
+++ b/arch/hexagon/kernel/dma.c
@@ -51,7 +51,7 @@ static struct gen_pool *coherent_pool;
 
 static void *hexagon_dma_alloc_coherent(struct device *dev, size_t size,
 dma_addr_t *dma_addr, gfp_t flag,
-struct dma_attrs *attrs)
+unsigned long attrs)
 {
void *ret;
 
@@ -84,7 +84,7 @@ static void *hexagon_dma_alloc_coherent(struct device *dev, 
size_t size,
 }
 
 static void hexagon_free_coherent(struct device *dev, size_t size, void *vaddr,
- dma_addr_t dma_addr, struct dma_attrs *attrs)
+ dma_addr_t dma_addr, unsigned long attrs)
 {
gen_pool_free(coherent_pool, (unsigned long) vaddr, size);
 }
@@ -105,7 +105,7 @@ static int check_addr(const char *name, struct device 
*hwdev,
 
 static int hexagon_map_sg(struct device *hwdev, struct scatterlist *sg,
  int nents, enum dma_data_direction dir,
- struct dma_attrs *attrs)
+ unsigned long attrs)
 {
struct scatterlist *s;
int i;
@@ -172,7 +172,7 @@ static inline void dma_sync(void *addr, size_t size,
 static dma_addr_t hexagon_map_page(struct device *dev, struct page *page,
   unsigned long offset, size_t size,
   enum dma_data_direction dir,
-  struct dma_attrs *attrs)
+  unsigned long attrs)
 {
dma_addr_t bus = page_to_phys(page) + offset;
WARN_ON(size == 0);
-- 
1.9.1


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


Re: [Xen-devel] [xen-unstable test] 95174: regressions - FAIL

2016-06-02 Thread Wei Liu
On Thu, Jun 02, 2016 at 03:41:33PM +, osstest service owner wrote:
> flight 95174 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/95174/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 5 xen-install fail REGR. vs. 
> 95129
> 

Failure when invoking apt-get install:

2016-06-02 06:25:01 Z executing ssh ... root@172.16.144.38 
DEBIAN_PRIORITY=critical UCF_FORCE_CONFFOLD=y \
with-lock-ex -w /var/lock/osstest-apt apt-get -y install 
libnl-route-3-200 
E: Could not get lock /var/lib/dpkg/lock - open (11: Resource temporarily 
unavailable)
E: Unable to lock the administration directory (/var/lib/dpkg/), is another 
process using it?

Though I'm not sure that the root cause of the failure is, I'm sure the
changes being tested won't affect a host like that.

Wei.

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


Re: [Xen-devel] [PATCH v1 for 4.7] Tmem cleanups.

2016-06-02 Thread Konrad Rzeszutek Wilk
On Thu, Jun 02, 2016 at 04:42:12PM +0100, Wei Liu wrote:
> On Thu, Jun 02, 2016 at 11:04:16AM -0400, Konrad Rzeszutek Wilk wrote:
> > Hey!
> > 
> > Since RFC [http://www.gossamer-threads.com/lists/xen/devel/431812]
> >  - Added Reviewed-by from Doug
> >  - Dropped the RFC
> > 
> > 
> > These four little cleanups move the bulk of tmem control ops
> > from tmem.c to tmem_control.c.
> > 
> > Last release I moved the control tmem ops from being part of tmem
> > hypercall to be part of the syscall subops - and this is the next
> > step in this cleanup. (See
> > http://lists.xen.org/archives/html/xen-devel/2015-10/msg03313.html)
> > which will allow me to follow up on the other steps:
> > b) Fix the toolstack (cleanup)
> > c) tmem tze, dedup, and zlib code drop
> > 
> > Anyhow sorry for this being so tardy - xSplice had more attention :-)
> > 
> 
> What do you mean here? There is no such thing called xSplice! :-P

Hehehe.
> 
> > Regression tests show no problems.
> > 
> > The patches themselves have no functionality changes thought I was itching
> > to remove most of the counters. I will do that going forward, but need
> > to figure out which ones make sense or if some of them can be coalesced. 
> > 
> > 
> >  xen/common/Makefile|   2 +-
> >  xen/common/tmem.c  | 618 
> > +
> >  xen/common/tmem_control.c  | 443 +
> >  xen/include/xen/tmem_control.h |  33 +++
> >  xen/include/xen/tmem_xen.h | 128 +
> >  5 files changed, 672 insertions(+), 552 deletions(-)
> > 
> 
> Since this is only tmem code, the only risk is it doesn't build in
> osstest, but I think the probability is quite low.
> 
> If you confirm that it builds on Debian Jessie, that would be good
> enough for me:

Sure thing. Will make sure and if there are no issues will
push it in staging.

Thanks!
> 
> Release-acked-by: Wei Liu 
> 
> > Konrad Rzeszutek Wilk (4):
> >   tmem: Move global stats in a tmem_statistics structure
> >   tmem: Wrap atomic_t in struct tmem_statistics as well.
> >   tmem: Move global_ individual variables in a global structure.
> >   tmem: Move bulk of tmem control functions in its own file.
> > 
> > ___
> > 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] [PATCH v1 for 4.7] Tmem cleanups.

2016-06-02 Thread Wei Liu
On Thu, Jun 02, 2016 at 11:04:16AM -0400, Konrad Rzeszutek Wilk wrote:
> Hey!
> 
> Since RFC [http://www.gossamer-threads.com/lists/xen/devel/431812]
>  - Added Reviewed-by from Doug
>  - Dropped the RFC
> 
> 
> These four little cleanups move the bulk of tmem control ops
> from tmem.c to tmem_control.c.
> 
> Last release I moved the control tmem ops from being part of tmem
> hypercall to be part of the syscall subops - and this is the next
> step in this cleanup. (See
> http://lists.xen.org/archives/html/xen-devel/2015-10/msg03313.html)
> which will allow me to follow up on the other steps:
> b) Fix the toolstack (cleanup)
> c) tmem tze, dedup, and zlib code drop
> 
> Anyhow sorry for this being so tardy - xSplice had more attention :-)
> 

What do you mean here? There is no such thing called xSplice! :-P

> Regression tests show no problems.
> 
> The patches themselves have no functionality changes thought I was itching
> to remove most of the counters. I will do that going forward, but need
> to figure out which ones make sense or if some of them can be coalesced. 
> 
> 
>  xen/common/Makefile|   2 +-
>  xen/common/tmem.c  | 618 
> +
>  xen/common/tmem_control.c  | 443 +
>  xen/include/xen/tmem_control.h |  33 +++
>  xen/include/xen/tmem_xen.h | 128 +
>  5 files changed, 672 insertions(+), 552 deletions(-)
> 

Since this is only tmem code, the only risk is it doesn't build in
osstest, but I think the probability is quite low.

If you confirm that it builds on Debian Jessie, that would be good
enough for me:

Release-acked-by: Wei Liu 

> Konrad Rzeszutek Wilk (4):
>   tmem: Move global stats in a tmem_statistics structure
>   tmem: Wrap atomic_t in struct tmem_statistics as well.
>   tmem: Move global_ individual variables in a global structure.
>   tmem: Move bulk of tmem control functions in its own file.
> 
> ___
> 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] [RFC v3 44/45] dma-mapping: Remove dma_get_attr

2016-06-02 Thread Krzysztof Kozlowski
After switching DMA attributes to unsigned long it is easier to just
compare the bits.

Signed-off-by: Krzysztof Kozlowski 
---
 Documentation/DMA-API.txt  |  4 +--
 arch/arc/mm/dma.c  |  4 +--
 arch/arm/mm/dma-mapping.c  | 36 --
 arch/arm/xen/mm.c  |  4 +--
 arch/arm64/mm/dma-mapping.c| 10 +++
 arch/avr32/mm/dma-coherent.c   |  4 +--
 arch/ia64/sn/pci/pci_dma.c | 10 ++-
 arch/metag/kernel/dma.c|  2 +-
 arch/mips/mm/dma-default.c |  6 ++---
 arch/openrisc/kernel/dma.c |  4 +--
 arch/parisc/kernel/pci-dma.c   |  2 +-
 arch/powerpc/platforms/cell/iommu.c| 10 +++
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c|  2 +-
 drivers/iommu/dma-iommu.c  |  2 +-
 drivers/media/v4l2-core/videobuf2-dma-contig.c |  2 +-
 include/linux/dma-mapping.h| 13 --
 16 files changed, 46 insertions(+), 69 deletions(-)

diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt
index 24f9688bb98a..1d26eeb6b5f6 100644
--- a/Documentation/DMA-API.txt
+++ b/Documentation/DMA-API.txt
@@ -422,9 +422,7 @@ void whizco_dma_map_sg_attrs(struct device *dev, dma_addr_t 
dma_addr,
 unsigned long attrs)
 {

-   int foo =  dma_get_attr(DMA_ATTR_FOO, attrs);
-   
-   if (foo)
+   if (attrs & DMA_ATTR_FOO)
/* twizzle the frobnozzle */

 
diff --git a/arch/arc/mm/dma.c b/arch/arc/mm/dma.c
index 3d1f467d1792..74bbe68dce9d 100644
--- a/arch/arc/mm/dma.c
+++ b/arch/arc/mm/dma.c
@@ -46,7 +46,7 @@ static void *arc_dma_alloc(struct device *dev, size_t size,
 *   (vs. always going to memory - thus are faster)
 */
if ((is_isa_arcv2() && ioc_exists) ||
-   dma_get_attr(DMA_ATTR_NON_CONSISTENT, attrs))
+   (attrs & DMA_ATTR_NON_CONSISTENT))
need_coh = 0;
 
/*
@@ -95,7 +95,7 @@ static void arc_dma_free(struct device *dev, size_t size, 
void *vaddr,
struct page *page = virt_to_page(dma_handle);
int is_non_coh = 1;
 
-   is_non_coh = dma_get_attr(DMA_ATTR_NON_CONSISTENT, attrs) ||
+   is_non_coh = (attrs & DMA_ATTR_NON_CONSISTENT) ||
(is_isa_arcv2() && ioc_exists);
 
if (PageHighMem(page) || !is_non_coh)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index ebb3fde99043..43e03b5293d0 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -126,7 +126,7 @@ static dma_addr_t arm_dma_map_page(struct device *dev, 
struct page *page,
 unsigned long offset, size_t size, enum dma_data_direction dir,
 unsigned long attrs)
 {
-   if (!dma_get_attr(DMA_ATTR_SKIP_CPU_SYNC, attrs))
+   if ((attrs & DMA_ATTR_SKIP_CPU_SYNC) == 0)
__dma_page_cpu_to_dev(page, offset, size, dir);
return pfn_to_dma(dev, page_to_pfn(page)) + offset;
 }
@@ -155,7 +155,7 @@ static dma_addr_t arm_coherent_dma_map_page(struct device 
*dev, struct page *pag
 static void arm_dma_unmap_page(struct device *dev, dma_addr_t handle,
size_t size, enum dma_data_direction dir, unsigned long attrs)
 {
-   if (!dma_get_attr(DMA_ATTR_SKIP_CPU_SYNC, attrs))
+   if ((attrs & DMA_ATTR_SKIP_CPU_SYNC) == 0)
__dma_page_dev_to_cpu(pfn_to_page(dma_to_pfn(dev, handle)),
  handle & ~PAGE_MASK, size, dir);
 }
@@ -622,9 +622,9 @@ static void __free_from_contiguous(struct device *dev, 
struct page *page,
 
 static inline pgprot_t __get_dma_pgprot(unsigned long attrs, pgprot_t prot)
 {
-   prot = dma_get_attr(DMA_ATTR_WRITE_COMBINE, attrs) ?
-   pgprot_writecombine(prot) :
-   pgprot_dmacoherent(prot);
+   prot = (attrs & DMA_ATTR_WRITE_COMBINE) ?
+   pgprot_writecombine(prot) :
+   pgprot_dmacoherent(prot);
return prot;
 }
 
@@ -744,7 +744,7 @@ static void *__dma_alloc(struct device *dev, size_t size, 
dma_addr_t *handle,
.gfp = gfp,
.prot = prot,
.caller = caller,
-   .want_vaddr = !dma_get_attr(DMA_ATTR_NO_KERNEL_MAPPING, attrs),
+   .want_vaddr = ((attrs & DMA_ATTR_NO_KERNEL_MAPPING) == 0),
};
 
 #ifdef CONFIG_DMA_API_DEBUG
@@ -887,7 +887,7 @@ static void __arm_dma_free(struct device *dev, size_t size, 
void *cpu_addr,
.size = PAGE_ALIGN(size),
.cpu_addr = cpu_addr,
.page = page,
-   .want_vaddr = !dma_get_attr(DMA_ATTR_NO_KERNEL_MAPPING, attrs),
+   .want_vaddr = ((attrs & DMA_ATTR_NO_KERNEL_MAPPING) == 0),
};
 
buf = 

[Xen-devel] [RFC v3 31/45] microblaze: dma-mapping: Use unsigned long for dma_attrs

2016-06-02 Thread Krzysztof Kozlowski
Split out subsystem specific changes for easier reviews. This will be
squashed with main commit.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/microblaze/include/asm/dma-mapping.h |  1 -
 arch/microblaze/kernel/dma.c  | 12 ++--
 2 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/arch/microblaze/include/asm/dma-mapping.h 
b/arch/microblaze/include/asm/dma-mapping.h
index 1884783d15c0..1768d4bdc8d3 100644
--- a/arch/microblaze/include/asm/dma-mapping.h
+++ b/arch/microblaze/include/asm/dma-mapping.h
@@ -25,7 +25,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
diff --git a/arch/microblaze/kernel/dma.c b/arch/microblaze/kernel/dma.c
index bf4dec229437..ec04dc1e2527 100644
--- a/arch/microblaze/kernel/dma.c
+++ b/arch/microblaze/kernel/dma.c
@@ -17,7 +17,7 @@
 
 static void *dma_direct_alloc_coherent(struct device *dev, size_t size,
   dma_addr_t *dma_handle, gfp_t flag,
-  struct dma_attrs *attrs)
+  unsigned long attrs)
 {
 #ifdef NOT_COHERENT_CACHE
return consistent_alloc(flag, size, dma_handle);
@@ -42,7 +42,7 @@ static void *dma_direct_alloc_coherent(struct device *dev, 
size_t size,
 
 static void dma_direct_free_coherent(struct device *dev, size_t size,
 void *vaddr, dma_addr_t dma_handle,
-struct dma_attrs *attrs)
+unsigned long attrs)
 {
 #ifdef NOT_COHERENT_CACHE
consistent_free(size, vaddr);
@@ -53,7 +53,7 @@ static void dma_direct_free_coherent(struct device *dev, 
size_t size,
 
 static int dma_direct_map_sg(struct device *dev, struct scatterlist *sgl,
 int nents, enum dma_data_direction direction,
-struct dma_attrs *attrs)
+unsigned long attrs)
 {
struct scatterlist *sg;
int i;
@@ -78,7 +78,7 @@ static inline dma_addr_t dma_direct_map_page(struct device 
*dev,
 unsigned long offset,
 size_t size,
 enum dma_data_direction direction,
-struct dma_attrs *attrs)
+unsigned long attrs)
 {
__dma_sync(page_to_phys(page) + offset, size, direction);
return page_to_phys(page) + offset;
@@ -88,7 +88,7 @@ static inline void dma_direct_unmap_page(struct device *dev,
 dma_addr_t dma_address,
 size_t size,
 enum dma_data_direction direction,
-struct dma_attrs *attrs)
+unsigned long attrs)
 {
 /* There is not necessary to do cache cleanup
  *
@@ -157,7 +157,7 @@ dma_direct_sync_sg_for_device(struct device *dev,
 static
 int dma_direct_mmap_coherent(struct device *dev, struct vm_area_struct *vma,
 void *cpu_addr, dma_addr_t handle, size_t size,
-struct dma_attrs *attrs)
+unsigned long attrs)
 {
 #ifdef CONFIG_MMU
unsigned long user_count = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
-- 
1.9.1


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


[Xen-devel] [RFC v3 29/45] m68k: dma-mapping: Use unsigned long for dma_attrs

2016-06-02 Thread Krzysztof Kozlowski
Split out subsystem specific changes for easier reviews. This will be
squashed with main commit.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/m68k/kernel/dma.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/m68k/kernel/dma.c b/arch/m68k/kernel/dma.c
index cbc78b4117b5..8cf97cbadc91 100644
--- a/arch/m68k/kernel/dma.c
+++ b/arch/m68k/kernel/dma.c
@@ -19,7 +19,7 @@
 #if defined(CONFIG_MMU) && !defined(CONFIG_COLDFIRE)
 
 static void *m68k_dma_alloc(struct device *dev, size_t size, dma_addr_t 
*handle,
-   gfp_t flag, struct dma_attrs *attrs)
+   gfp_t flag, unsigned long attrs)
 {
struct page *page, **map;
pgprot_t pgprot;
@@ -62,7 +62,7 @@ static void *m68k_dma_alloc(struct device *dev, size_t size, 
dma_addr_t *handle,
 }
 
 static void m68k_dma_free(struct device *dev, size_t size, void *addr,
-   dma_addr_t handle, struct dma_attrs *attrs)
+   dma_addr_t handle, unsigned long attrs)
 {
pr_debug("dma_free_coherent: %p, %x\n", addr, handle);
vfree(addr);
@@ -73,7 +73,7 @@ static void m68k_dma_free(struct device *dev, size_t size, 
void *addr,
 #include 
 
 static void *m68k_dma_alloc(struct device *dev, size_t size,
-   dma_addr_t *dma_handle, gfp_t gfp, struct dma_attrs *attrs)
+   dma_addr_t *dma_handle, gfp_t gfp, unsigned long attrs)
 {
void *ret;
/* ignore region specifiers */
@@ -91,7 +91,7 @@ static void *m68k_dma_alloc(struct device *dev, size_t size,
 }
 
 static void m68k_dma_free(struct device *dev, size_t size, void *vaddr,
-   dma_addr_t dma_handle, struct dma_attrs *attrs)
+   dma_addr_t dma_handle, unsigned long attrs)
 {
free_pages((unsigned long)vaddr, get_order(size));
 }
@@ -130,7 +130,7 @@ static void m68k_dma_sync_sg_for_device(struct device *dev,
 
 static dma_addr_t m68k_dma_map_page(struct device *dev, struct page *page,
unsigned long offset, size_t size, enum dma_data_direction dir,
-   struct dma_attrs *attrs)
+   unsigned long attrs)
 {
dma_addr_t handle = page_to_phys(page) + offset;
 
@@ -139,7 +139,7 @@ static dma_addr_t m68k_dma_map_page(struct device *dev, 
struct page *page,
 }
 
 static int m68k_dma_map_sg(struct device *dev, struct scatterlist *sglist,
-   int nents, enum dma_data_direction dir, struct dma_attrs *attrs)
+   int nents, enum dma_data_direction dir, unsigned long attrs)
 {
int i;
struct scatterlist *sg;
-- 
1.9.1


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


[Xen-devel] [RFC v3 36/45] parisc: dma-mapping: Use unsigned long for dma_attrs

2016-06-02 Thread Krzysztof Kozlowski
Split out subsystem specific changes for easier reviews. This will be
squashed with main commit.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/parisc/kernel/pci-dma.c | 16 
 drivers/parisc/ccio-dma.c| 16 
 drivers/parisc/sba_iommu.c   | 16 
 3 files changed, 24 insertions(+), 24 deletions(-)

diff --git a/arch/parisc/kernel/pci-dma.c b/arch/parisc/kernel/pci-dma.c
index a27e4928bf73..845fdd52e4c5 100644
--- a/arch/parisc/kernel/pci-dma.c
+++ b/arch/parisc/kernel/pci-dma.c
@@ -414,7 +414,7 @@ pcxl_dma_init(void)
 __initcall(pcxl_dma_init);
 
 static void *pa11_dma_alloc(struct device *dev, size_t size,
-   dma_addr_t *dma_handle, gfp_t flag, struct dma_attrs *attrs)
+   dma_addr_t *dma_handle, gfp_t flag, unsigned long attrs)
 {
unsigned long vaddr;
unsigned long paddr;
@@ -441,7 +441,7 @@ static void *pa11_dma_alloc(struct device *dev, size_t size,
 }
 
 static void pa11_dma_free(struct device *dev, size_t size, void *vaddr,
-   dma_addr_t dma_handle, struct dma_attrs *attrs)
+   dma_addr_t dma_handle, unsigned long attrs)
 {
int order;
 
@@ -454,7 +454,7 @@ static void pa11_dma_free(struct device *dev, size_t size, 
void *vaddr,
 
 static dma_addr_t pa11_dma_map_page(struct device *dev, struct page *page,
unsigned long offset, size_t size,
-   enum dma_data_direction direction, struct dma_attrs *attrs)
+   enum dma_data_direction direction, unsigned long attrs)
 {
void *addr = page_address(page) + offset;
BUG_ON(direction == DMA_NONE);
@@ -465,7 +465,7 @@ static dma_addr_t pa11_dma_map_page(struct device *dev, 
struct page *page,
 
 static void pa11_dma_unmap_page(struct device *dev, dma_addr_t dma_handle,
size_t size, enum dma_data_direction direction,
-   struct dma_attrs *attrs)
+   unsigned long attrs)
 {
BUG_ON(direction == DMA_NONE);
 
@@ -484,7 +484,7 @@ static void pa11_dma_unmap_page(struct device *dev, 
dma_addr_t dma_handle,
 
 static int pa11_dma_map_sg(struct device *dev, struct scatterlist *sglist,
int nents, enum dma_data_direction direction,
-   struct dma_attrs *attrs)
+   unsigned long attrs)
 {
int i;
struct scatterlist *sg;
@@ -503,7 +503,7 @@ static int pa11_dma_map_sg(struct device *dev, struct 
scatterlist *sglist,
 
 static void pa11_dma_unmap_sg(struct device *dev, struct scatterlist *sglist,
int nents, enum dma_data_direction direction,
-   struct dma_attrs *attrs)
+   unsigned long attrs)
 {
int i;
struct scatterlist *sg;
@@ -577,7 +577,7 @@ struct dma_map_ops pcxl_dma_ops = {
 };
 
 static void *pcx_dma_alloc(struct device *dev, size_t size,
-   dma_addr_t *dma_handle, gfp_t flag, struct dma_attrs *attrs)
+   dma_addr_t *dma_handle, gfp_t flag, unsigned long attrs)
 {
void *addr;
 
@@ -592,7 +592,7 @@ static void *pcx_dma_alloc(struct device *dev, size_t size,
 }
 
 static void pcx_dma_free(struct device *dev, size_t size, void *vaddr,
-   dma_addr_t iova, struct dma_attrs *attrs)
+   dma_addr_t iova, unsigned long attrs)
 {
free_pages((unsigned long)vaddr, get_order(size));
return;
diff --git a/drivers/parisc/ccio-dma.c b/drivers/parisc/ccio-dma.c
index e24b05996a1b..3ed6238f8f6e 100644
--- a/drivers/parisc/ccio-dma.c
+++ b/drivers/parisc/ccio-dma.c
@@ -790,7 +790,7 @@ ccio_map_single(struct device *dev, void *addr, size_t size,
 static dma_addr_t
 ccio_map_page(struct device *dev, struct page *page, unsigned long offset,
size_t size, enum dma_data_direction direction,
-   struct dma_attrs *attrs)
+   unsigned long attrs)
 {
return ccio_map_single(dev, page_address(page) + offset, size,
direction);
@@ -806,7 +806,7 @@ ccio_map_page(struct device *dev, struct page *page, 
unsigned long offset,
  */
 static void 
 ccio_unmap_page(struct device *dev, dma_addr_t iova, size_t size,
-   enum dma_data_direction direction, struct dma_attrs *attrs)
+   enum dma_data_direction direction, unsigned long attrs)
 {
struct ioc *ioc;
unsigned long flags; 
@@ -844,7 +844,7 @@ ccio_unmap_page(struct device *dev, dma_addr_t iova, size_t 
size,
  */
 static void * 
 ccio_alloc(struct device *dev, size_t size, dma_addr_t *dma_handle, gfp_t flag,
-   struct dma_attrs *attrs)
+   unsigned long attrs)
 {
   void *ret;
 #if 0
@@ -878,9 +878,9 @@ ccio_alloc(struct device *dev, size_t size, dma_addr_t 
*dma_handle, gfp_t flag,
  */
 static void 
 ccio_free(struct device *dev, size_t size, void *cpu_addr,
-   dma_addr_t dma_handle, struct dma_attrs *attrs)
+   dma_addr_t dma_handle, unsigned long attrs)
 {
-  

[Xen-devel] [RFC v3 40/45] sparc: dma-mapping: Use unsigned long for dma_attrs

2016-06-02 Thread Krzysztof Kozlowski
Split out subsystem specific changes for easier reviews. This will be
squashed with main commit.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/sparc/kernel/iommu.c | 12 ++--
 arch/sparc/kernel/ioport.c| 24 
 arch/sparc/kernel/pci_sun4v.c | 12 ++--
 3 files changed, 24 insertions(+), 24 deletions(-)

diff --git a/arch/sparc/kernel/iommu.c b/arch/sparc/kernel/iommu.c
index 37686828c3d9..5c615abff030 100644
--- a/arch/sparc/kernel/iommu.c
+++ b/arch/sparc/kernel/iommu.c
@@ -196,7 +196,7 @@ static inline void iommu_free_ctx(struct iommu *iommu, int 
ctx)
 
 static void *dma_4u_alloc_coherent(struct device *dev, size_t size,
   dma_addr_t *dma_addrp, gfp_t gfp,
-  struct dma_attrs *attrs)
+  unsigned long attrs)
 {
unsigned long order, first_page;
struct iommu *iommu;
@@ -245,7 +245,7 @@ static void *dma_4u_alloc_coherent(struct device *dev, 
size_t size,
 
 static void dma_4u_free_coherent(struct device *dev, size_t size,
 void *cpu, dma_addr_t dvma,
-struct dma_attrs *attrs)
+unsigned long attrs)
 {
struct iommu *iommu;
unsigned long order, npages;
@@ -263,7 +263,7 @@ static void dma_4u_free_coherent(struct device *dev, size_t 
size,
 static dma_addr_t dma_4u_map_page(struct device *dev, struct page *page,
  unsigned long offset, size_t sz,
  enum dma_data_direction direction,
- struct dma_attrs *attrs)
+ unsigned long attrs)
 {
struct iommu *iommu;
struct strbuf *strbuf;
@@ -385,7 +385,7 @@ do_flush_sync:
 
 static void dma_4u_unmap_page(struct device *dev, dma_addr_t bus_addr,
  size_t sz, enum dma_data_direction direction,
- struct dma_attrs *attrs)
+ unsigned long attrs)
 {
struct iommu *iommu;
struct strbuf *strbuf;
@@ -431,7 +431,7 @@ static void dma_4u_unmap_page(struct device *dev, 
dma_addr_t bus_addr,
 
 static int dma_4u_map_sg(struct device *dev, struct scatterlist *sglist,
 int nelems, enum dma_data_direction direction,
-struct dma_attrs *attrs)
+unsigned long attrs)
 {
struct scatterlist *s, *outs, *segstart;
unsigned long flags, handle, prot, ctx;
@@ -607,7 +607,7 @@ static unsigned long fetch_sg_ctx(struct iommu *iommu, 
struct scatterlist *sg)
 
 static void dma_4u_unmap_sg(struct device *dev, struct scatterlist *sglist,
int nelems, enum dma_data_direction direction,
-   struct dma_attrs *attrs)
+   unsigned long attrs)
 {
unsigned long flags, ctx;
struct scatterlist *sg;
diff --git a/arch/sparc/kernel/ioport.c b/arch/sparc/kernel/ioport.c
index ffd5ff4678cf..2344103414d1 100644
--- a/arch/sparc/kernel/ioport.c
+++ b/arch/sparc/kernel/ioport.c
@@ -260,7 +260,7 @@ EXPORT_SYMBOL(sbus_set_sbus64);
  */
 static void *sbus_alloc_coherent(struct device *dev, size_t len,
 dma_addr_t *dma_addrp, gfp_t gfp,
-struct dma_attrs *attrs)
+unsigned long attrs)
 {
struct platform_device *op = to_platform_device(dev);
unsigned long len_total = PAGE_ALIGN(len);
@@ -315,7 +315,7 @@ err_nopages:
 }
 
 static void sbus_free_coherent(struct device *dev, size_t n, void *p,
-  dma_addr_t ba, struct dma_attrs *attrs)
+  dma_addr_t ba, unsigned long attrs)
 {
struct resource *res;
struct page *pgv;
@@ -355,7 +355,7 @@ static void sbus_free_coherent(struct device *dev, size_t 
n, void *p,
 static dma_addr_t sbus_map_page(struct device *dev, struct page *page,
unsigned long offset, size_t len,
enum dma_data_direction dir,
-   struct dma_attrs *attrs)
+   unsigned long attrs)
 {
void *va = page_address(page) + offset;
 
@@ -371,20 +371,20 @@ static dma_addr_t sbus_map_page(struct device *dev, 
struct page *page,
 }
 
 static void sbus_unmap_page(struct device *dev, dma_addr_t ba, size_t n,
-   enum dma_data_direction dir, struct dma_attrs 
*attrs)
+   enum dma_data_direction dir, unsigned long attrs)
 {
mmu_release_scsi_one(dev, ba, n);
 }
 
 static int sbus_map_sg(struct device *dev, struct scatterlist *sg, int n,
-  enum dma_data_direction dir, struct dma_attrs *attrs)
+  enum dma_data_direction dir, unsigned 

[Xen-devel] [RFC v3 39/45] sh: dma-mapping: Use unsigned long for dma_attrs

2016-06-02 Thread Krzysztof Kozlowski
Split out subsystem specific changes for easier reviews. This will be
squashed with main commit.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/sh/include/asm/dma-mapping.h | 4 ++--
 arch/sh/kernel/dma-nommu.c| 4 ++--
 arch/sh/mm/consistent.c   | 4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/sh/include/asm/dma-mapping.h 
b/arch/sh/include/asm/dma-mapping.h
index e11cf0c8206b..0052ad40e86d 100644
--- a/arch/sh/include/asm/dma-mapping.h
+++ b/arch/sh/include/asm/dma-mapping.h
@@ -17,9 +17,9 @@ void dma_cache_sync(struct device *dev, void *vaddr, size_t 
size,
 /* arch/sh/mm/consistent.c */
 extern void *dma_generic_alloc_coherent(struct device *dev, size_t size,
dma_addr_t *dma_addr, gfp_t flag,
-   struct dma_attrs *attrs);
+   unsigned long attrs);
 extern void dma_generic_free_coherent(struct device *dev, size_t size,
  void *vaddr, dma_addr_t dma_handle,
- struct dma_attrs *attrs);
+ unsigned long attrs);
 
 #endif /* __ASM_SH_DMA_MAPPING_H */
diff --git a/arch/sh/kernel/dma-nommu.c b/arch/sh/kernel/dma-nommu.c
index 5b0bfcda6d0b..eadb669a7329 100644
--- a/arch/sh/kernel/dma-nommu.c
+++ b/arch/sh/kernel/dma-nommu.c
@@ -13,7 +13,7 @@
 static dma_addr_t nommu_map_page(struct device *dev, struct page *page,
 unsigned long offset, size_t size,
 enum dma_data_direction dir,
-struct dma_attrs *attrs)
+unsigned long attrs)
 {
dma_addr_t addr = page_to_phys(page) + offset;
 
@@ -25,7 +25,7 @@ static dma_addr_t nommu_map_page(struct device *dev, struct 
page *page,
 
 static int nommu_map_sg(struct device *dev, struct scatterlist *sg,
int nents, enum dma_data_direction dir,
-   struct dma_attrs *attrs)
+   unsigned long attrs)
 {
struct scatterlist *s;
int i;
diff --git a/arch/sh/mm/consistent.c b/arch/sh/mm/consistent.c
index b81d9dbf9fef..92b6976fde59 100644
--- a/arch/sh/mm/consistent.c
+++ b/arch/sh/mm/consistent.c
@@ -34,7 +34,7 @@ fs_initcall(dma_init);
 
 void *dma_generic_alloc_coherent(struct device *dev, size_t size,
 dma_addr_t *dma_handle, gfp_t gfp,
-struct dma_attrs *attrs)
+unsigned long attrs)
 {
void *ret, *ret_nocache;
int order = get_order(size);
@@ -66,7 +66,7 @@ void *dma_generic_alloc_coherent(struct device *dev, size_t 
size,
 
 void dma_generic_free_coherent(struct device *dev, size_t size,
   void *vaddr, dma_addr_t dma_handle,
-  struct dma_attrs *attrs)
+  unsigned long attrs)
 {
int order = get_order(size);
unsigned long pfn = dma_handle >> PAGE_SHIFT;
-- 
1.9.1


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


[Xen-devel] [RFC v3 43/45] xtensa: dma-mapping: Use unsigned long for dma_attrs

2016-06-02 Thread Krzysztof Kozlowski
Split out subsystem specific changes for easier reviews. This will be
squashed with main commit.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/xtensa/kernel/pci-dma.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/xtensa/kernel/pci-dma.c b/arch/xtensa/kernel/pci-dma.c
index cd66698348ca..1e68806d6695 100644
--- a/arch/xtensa/kernel/pci-dma.c
+++ b/arch/xtensa/kernel/pci-dma.c
@@ -142,7 +142,7 @@ static void xtensa_sync_sg_for_device(struct device *dev,
 
 static void *xtensa_dma_alloc(struct device *dev, size_t size,
  dma_addr_t *handle, gfp_t flag,
- struct dma_attrs *attrs)
+ unsigned long attrs)
 {
unsigned long ret;
unsigned long uncached = 0;
@@ -171,7 +171,7 @@ static void *xtensa_dma_alloc(struct device *dev, size_t 
size,
 }
 
 static void xtensa_dma_free(struct device *hwdev, size_t size, void *vaddr,
-   dma_addr_t dma_handle, struct dma_attrs *attrs)
+   dma_addr_t dma_handle, unsigned long attrs)
 {
unsigned long addr = (unsigned long)vaddr +
XCHAL_KSEG_CACHED_VADDR - XCHAL_KSEG_BYPASS_VADDR;
@@ -185,7 +185,7 @@ static void xtensa_dma_free(struct device *hwdev, size_t 
size, void *vaddr,
 static dma_addr_t xtensa_map_page(struct device *dev, struct page *page,
  unsigned long offset, size_t size,
  enum dma_data_direction dir,
- struct dma_attrs *attrs)
+ unsigned long attrs)
 {
dma_addr_t dma_handle = page_to_phys(page) + offset;
 
@@ -195,14 +195,14 @@ static dma_addr_t xtensa_map_page(struct device *dev, 
struct page *page,
 
 static void xtensa_unmap_page(struct device *dev, dma_addr_t dma_handle,
  size_t size, enum dma_data_direction dir,
- struct dma_attrs *attrs)
+ unsigned long attrs)
 {
xtensa_sync_single_for_cpu(dev, dma_handle, size, dir);
 }
 
 static int xtensa_map_sg(struct device *dev, struct scatterlist *sg,
 int nents, enum dma_data_direction dir,
-struct dma_attrs *attrs)
+unsigned long attrs)
 {
struct scatterlist *s;
int i;
@@ -217,7 +217,7 @@ static int xtensa_map_sg(struct device *dev, struct 
scatterlist *sg,
 static void xtensa_unmap_sg(struct device *dev,
struct scatterlist *sg, int nents,
enum dma_data_direction dir,
-   struct dma_attrs *attrs)
+   unsigned long attrs)
 {
struct scatterlist *s;
int i;
-- 
1.9.1


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


[Xen-devel] [RFC v3 38/45] s390: dma-mapping: Use unsigned long for dma_attrs

2016-06-02 Thread Krzysztof Kozlowski
Split out subsystem specific changes for easier reviews. This will be
squashed with main commit.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/s390/include/asm/dma-mapping.h |  1 -
 arch/s390/pci/pci_dma.c | 23 ---
 2 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/arch/s390/include/asm/dma-mapping.h 
b/arch/s390/include/asm/dma-mapping.h
index 3249b7464889..ffaba07f50ab 100644
--- a/arch/s390/include/asm/dma-mapping.h
+++ b/arch/s390/include/asm/dma-mapping.h
@@ -5,7 +5,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
diff --git a/arch/s390/pci/pci_dma.c b/arch/s390/pci/pci_dma.c
index 1ea8c07eab84..159f767f9011 100644
--- a/arch/s390/pci/pci_dma.c
+++ b/arch/s390/pci/pci_dma.c
@@ -285,7 +285,7 @@ static inline void zpci_err_dma(unsigned long rc, unsigned 
long addr)
 static dma_addr_t s390_dma_map_pages(struct device *dev, struct page *page,
 unsigned long offset, size_t size,
 enum dma_data_direction direction,
-struct dma_attrs *attrs)
+unsigned long attrs)
 {
struct zpci_dev *zdev = to_zpci(to_pci_dev(dev));
unsigned long nr_pages, iommu_page_index;
@@ -331,7 +331,7 @@ out_err:
 
 static void s390_dma_unmap_pages(struct device *dev, dma_addr_t dma_addr,
 size_t size, enum dma_data_direction direction,
-struct dma_attrs *attrs)
+unsigned long attrs)
 {
struct zpci_dev *zdev = to_zpci(to_pci_dev(dev));
unsigned long iommu_page_index;
@@ -354,7 +354,7 @@ static void s390_dma_unmap_pages(struct device *dev, 
dma_addr_t dma_addr,
 
 static void *s390_dma_alloc(struct device *dev, size_t size,
dma_addr_t *dma_handle, gfp_t flag,
-   struct dma_attrs *attrs)
+   unsigned long attrs)
 {
struct zpci_dev *zdev = to_zpci(to_pci_dev(dev));
struct page *page;
@@ -369,7 +369,7 @@ static void *s390_dma_alloc(struct device *dev, size_t size,
pa = page_to_phys(page);
memset((void *) pa, 0, size);
 
-   map = s390_dma_map_pages(dev, page, 0, size, DMA_BIDIRECTIONAL, NULL);
+   map = s390_dma_map_pages(dev, page, 0, size, DMA_BIDIRECTIONAL, 0);
if (dma_mapping_error(dev, map)) {
free_pages(pa, get_order(size));
return NULL;
@@ -383,19 +383,19 @@ static void *s390_dma_alloc(struct device *dev, size_t 
size,
 
 static void s390_dma_free(struct device *dev, size_t size,
  void *pa, dma_addr_t dma_handle,
- struct dma_attrs *attrs)
+ unsigned long attrs)
 {
struct zpci_dev *zdev = to_zpci(to_pci_dev(dev));
 
size = PAGE_ALIGN(size);
atomic64_sub(size / PAGE_SIZE, >allocated_pages);
-   s390_dma_unmap_pages(dev, dma_handle, size, DMA_BIDIRECTIONAL, NULL);
+   s390_dma_unmap_pages(dev, dma_handle, size, DMA_BIDIRECTIONAL, 0);
free_pages((unsigned long) pa, get_order(size));
 }
 
 static int s390_dma_map_sg(struct device *dev, struct scatterlist *sg,
   int nr_elements, enum dma_data_direction dir,
-  struct dma_attrs *attrs)
+  unsigned long attrs)
 {
int mapped_elements = 0;
struct scatterlist *s;
@@ -404,7 +404,7 @@ static int s390_dma_map_sg(struct device *dev, struct 
scatterlist *sg,
for_each_sg(sg, s, nr_elements, i) {
struct page *page = sg_page(s);
s->dma_address = s390_dma_map_pages(dev, page, s->offset,
-   s->length, dir, NULL);
+   s->length, dir, 0);
if (!dma_mapping_error(dev, s->dma_address)) {
s->dma_length = s->length;
mapped_elements++;
@@ -418,7 +418,7 @@ unmap:
for_each_sg(sg, s, mapped_elements, i) {
if (s->dma_address)
s390_dma_unmap_pages(dev, s->dma_address, s->dma_length,
-dir, NULL);
+dir, 0);
s->dma_address = 0;
s->dma_length = 0;
}
@@ -428,13 +428,14 @@ unmap:
 
 static void s390_dma_unmap_sg(struct device *dev, struct scatterlist *sg,
  int nr_elements, enum dma_data_direction dir,
- struct dma_attrs *attrs)
+ unsigned long attrs)
 {
struct scatterlist *s;
int i;
 
for_each_sg(sg, s, nr_elements, i) {
-   s390_dma_unmap_pages(dev, s->dma_address, s->dma_length, dir, 
NULL);
+   

[Xen-devel] [RFC v3 42/45] unicore32: dma-mapping: Use unsigned long for dma_attrs

2016-06-02 Thread Krzysztof Kozlowski
Split out subsystem specific changes for easier reviews. This will be
squashed with main commit.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/unicore32/mm/dma-swiotlb.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/unicore32/mm/dma-swiotlb.c b/arch/unicore32/mm/dma-swiotlb.c
index 16c08b2143a7..3e9f6489ba38 100644
--- a/arch/unicore32/mm/dma-swiotlb.c
+++ b/arch/unicore32/mm/dma-swiotlb.c
@@ -19,14 +19,14 @@
 
 static void *unicore_swiotlb_alloc_coherent(struct device *dev, size_t size,
dma_addr_t *dma_handle, gfp_t flags,
-   struct dma_attrs *attrs)
+   unsigned long attrs)
 {
return swiotlb_alloc_coherent(dev, size, dma_handle, flags);
 }
 
 static void unicore_swiotlb_free_coherent(struct device *dev, size_t size,
  void *vaddr, dma_addr_t dma_addr,
- struct dma_attrs *attrs)
+ unsigned long attrs)
 {
swiotlb_free_coherent(dev, size, vaddr, dma_addr);
 }
-- 
1.9.1


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


[Xen-devel] [RFC v3 45/45] dma-mapping: Document the DMA attributes right in declaration

2016-06-02 Thread Krzysztof Kozlowski
Copy documentation abstract about each DMA attribute from
Documentation/DMA-attributes.txt to the place with declaration.

Suggested-by: Christoph Hellwig 
Signed-off-by: Krzysztof Kozlowski 
---
 include/linux/dma-mapping.h | 33 +
 1 file changed, 33 insertions(+)

diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 6d013ba94213..f349df4cb009 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -14,14 +14,47 @@
 /**
  * List of possible attributes associated with a DMA mapping. The semantics
  * of each attribute should be defined in Documentation/DMA-attributes.txt.
+ *
+ * DMA_ATTR_WRITE_BARRIER: DMA to a memory region with this attribute
+ * forces all pending DMA writes to complete.
  */
 #define DMA_ATTR_WRITE_BARRIER (1UL << 1)
+/*
+ * DMA_ATTR_WEAK_ORDERING: Specifies that reads and writes to the mapping
+ * may be weakly ordered, that is that reads and writes may pass each other.
+ */
 #define DMA_ATTR_WEAK_ORDERING (1UL << 2)
+/*
+ * DMA_ATTR_WRITE_COMBINE: Specifies that writes to the mapping may be
+ * buffered to improve performance.
+ */
 #define DMA_ATTR_WRITE_COMBINE (1UL << 3)
+/*
+ * DMA_ATTR_NON_CONSISTENT: Lets the platform to choose to return either
+ * consistent or non-consistent memory as it sees fit.
+ */
 #define DMA_ATTR_NON_CONSISTENT(1UL << 4)
+/*
+ * DMA_ATTR_NO_KERNEL_MAPPING: Lets the platform to avoid creating a kernel
+ * virtual mapping for the allocated buffer.
+ */
 #define DMA_ATTR_NO_KERNEL_MAPPING (1UL << 5)
+/*
+ * DMA_ATTR_SKIP_CPU_SYNC: Allows platform code to skip synchronization of
+ * the CPU cache for the given buffer assuming that it has been already
+ * transferred to 'device' domain.
+ */
 #define DMA_ATTR_SKIP_CPU_SYNC (1UL << 6)
+/*
+ * DMA_ATTR_FORCE_CONTIGUOUS: Forces contiguous allocation of the buffer
+ * in physical memory.
+ */
 #define DMA_ATTR_FORCE_CONTIGUOUS  (1UL << 7)
+/*
+ * DMA_ATTR_ALLOC_SINGLE_PAGES: This is a hint to the DMA-mapping subsystem
+ * that it's probably not worth the time to try to allocate memory to in a way
+ * that gives better TLB efficiency.
+ */
 #define DMA_ATTR_ALLOC_SINGLE_PAGES(1UL << 8)
 
 /*
-- 
1.9.1


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


[Xen-devel] [RFC v3 41/45] tile: dma-mapping: Use unsigned long for dma_attrs

2016-06-02 Thread Krzysztof Kozlowski
Split out subsystem specific changes for easier reviews. This will be
squashed with main commit.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/tile/kernel/pci-dma.c | 28 ++--
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/arch/tile/kernel/pci-dma.c b/arch/tile/kernel/pci-dma.c
index b6bc0547a4f6..09bb774b39cd 100644
--- a/arch/tile/kernel/pci-dma.c
+++ b/arch/tile/kernel/pci-dma.c
@@ -34,7 +34,7 @@
 
 static void *tile_dma_alloc_coherent(struct device *dev, size_t size,
 dma_addr_t *dma_handle, gfp_t gfp,
-struct dma_attrs *attrs)
+unsigned long attrs)
 {
u64 dma_mask = (dev && dev->coherent_dma_mask) ?
dev->coherent_dma_mask : DMA_BIT_MASK(32);
@@ -78,7 +78,7 @@ static void *tile_dma_alloc_coherent(struct device *dev, 
size_t size,
  */
 static void tile_dma_free_coherent(struct device *dev, size_t size,
   void *vaddr, dma_addr_t dma_handle,
-  struct dma_attrs *attrs)
+  unsigned long attrs)
 {
homecache_free_pages((unsigned long)vaddr, get_order(size));
 }
@@ -202,7 +202,7 @@ static void __dma_complete_pa_range(dma_addr_t dma_addr, 
size_t size,
 
 static int tile_dma_map_sg(struct device *dev, struct scatterlist *sglist,
   int nents, enum dma_data_direction direction,
-  struct dma_attrs *attrs)
+  unsigned long attrs)
 {
struct scatterlist *sg;
int i;
@@ -224,7 +224,7 @@ static int tile_dma_map_sg(struct device *dev, struct 
scatterlist *sglist,
 
 static void tile_dma_unmap_sg(struct device *dev, struct scatterlist *sglist,
  int nents, enum dma_data_direction direction,
- struct dma_attrs *attrs)
+ unsigned long attrs)
 {
struct scatterlist *sg;
int i;
@@ -240,7 +240,7 @@ static void tile_dma_unmap_sg(struct device *dev, struct 
scatterlist *sglist,
 static dma_addr_t tile_dma_map_page(struct device *dev, struct page *page,
unsigned long offset, size_t size,
enum dma_data_direction direction,
-   struct dma_attrs *attrs)
+   unsigned long attrs)
 {
BUG_ON(!valid_dma_direction(direction));
 
@@ -252,7 +252,7 @@ static dma_addr_t tile_dma_map_page(struct device *dev, 
struct page *page,
 
 static void tile_dma_unmap_page(struct device *dev, dma_addr_t dma_address,
size_t size, enum dma_data_direction direction,
-   struct dma_attrs *attrs)
+   unsigned long attrs)
 {
BUG_ON(!valid_dma_direction(direction));
 
@@ -343,7 +343,7 @@ EXPORT_SYMBOL(tile_dma_map_ops);
 
 static void *tile_pci_dma_alloc_coherent(struct device *dev, size_t size,
 dma_addr_t *dma_handle, gfp_t gfp,
-struct dma_attrs *attrs)
+unsigned long attrs)
 {
int node = dev_to_node(dev);
int order = get_order(size);
@@ -368,14 +368,14 @@ static void *tile_pci_dma_alloc_coherent(struct device 
*dev, size_t size,
  */
 static void tile_pci_dma_free_coherent(struct device *dev, size_t size,
   void *vaddr, dma_addr_t dma_handle,
-  struct dma_attrs *attrs)
+  unsigned long attrs)
 {
homecache_free_pages((unsigned long)vaddr, get_order(size));
 }
 
 static int tile_pci_dma_map_sg(struct device *dev, struct scatterlist *sglist,
   int nents, enum dma_data_direction direction,
-  struct dma_attrs *attrs)
+  unsigned long attrs)
 {
struct scatterlist *sg;
int i;
@@ -400,7 +400,7 @@ static int tile_pci_dma_map_sg(struct device *dev, struct 
scatterlist *sglist,
 static void tile_pci_dma_unmap_sg(struct device *dev,
  struct scatterlist *sglist, int nents,
  enum dma_data_direction direction,
- struct dma_attrs *attrs)
+ unsigned long attrs)
 {
struct scatterlist *sg;
int i;
@@ -416,7 +416,7 @@ static void tile_pci_dma_unmap_sg(struct device *dev,
 static dma_addr_t tile_pci_dma_map_page(struct device *dev, struct page *page,
unsigned long offset, size_t size,
enum dma_data_direction direction,
-   struct dma_attrs *attrs)
+   

[Xen-devel] [RFC v3 37/45] misc: mic: dma-mapping: Use unsigned long for dma_attrs

2016-06-02 Thread Krzysztof Kozlowski
Split out subsystem specific changes for easier reviews. This will be
squashed with main commit.

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/misc/mic/host/mic_boot.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/misc/mic/host/mic_boot.c b/drivers/misc/mic/host/mic_boot.c
index e047efd83f57..9599d732aff3 100644
--- a/drivers/misc/mic/host/mic_boot.c
+++ b/drivers/misc/mic/host/mic_boot.c
@@ -38,7 +38,7 @@ static inline struct mic_device *vpdev_to_mdev(struct device 
*dev)
 static dma_addr_t
 _mic_dma_map_page(struct device *dev, struct page *page,
  unsigned long offset, size_t size,
- enum dma_data_direction dir, struct dma_attrs *attrs)
+ enum dma_data_direction dir, unsigned long attrs)
 {
void *va = phys_to_virt(page_to_phys(page)) + offset;
struct mic_device *mdev = vpdev_to_mdev(dev);
@@ -48,7 +48,7 @@ _mic_dma_map_page(struct device *dev, struct page *page,
 
 static void _mic_dma_unmap_page(struct device *dev, dma_addr_t dma_addr,
size_t size, enum dma_data_direction dir,
-   struct dma_attrs *attrs)
+   unsigned long attrs)
 {
struct mic_device *mdev = vpdev_to_mdev(dev);
 
@@ -144,7 +144,7 @@ static inline struct mic_device *scdev_to_mdev(struct 
scif_hw_dev *scdev)
 
 static void *__mic_dma_alloc(struct device *dev, size_t size,
 dma_addr_t *dma_handle, gfp_t gfp,
-struct dma_attrs *attrs)
+unsigned long attrs)
 {
struct scif_hw_dev *scdev = dev_get_drvdata(dev);
struct mic_device *mdev = scdev_to_mdev(scdev);
@@ -164,7 +164,7 @@ static void *__mic_dma_alloc(struct device *dev, size_t 
size,
 }
 
 static void __mic_dma_free(struct device *dev, size_t size, void *vaddr,
-  dma_addr_t dma_handle, struct dma_attrs *attrs)
+  dma_addr_t dma_handle, unsigned long attrs)
 {
struct scif_hw_dev *scdev = dev_get_drvdata(dev);
struct mic_device *mdev = scdev_to_mdev(scdev);
@@ -176,7 +176,7 @@ static void __mic_dma_free(struct device *dev, size_t size, 
void *vaddr,
 static dma_addr_t
 __mic_dma_map_page(struct device *dev, struct page *page, unsigned long offset,
   size_t size, enum dma_data_direction dir,
-  struct dma_attrs *attrs)
+  unsigned long attrs)
 {
void *va = phys_to_virt(page_to_phys(page)) + offset;
struct scif_hw_dev *scdev = dev_get_drvdata(dev);
@@ -188,7 +188,7 @@ __mic_dma_map_page(struct device *dev, struct page *page, 
unsigned long offset,
 static void
 __mic_dma_unmap_page(struct device *dev, dma_addr_t dma_addr,
 size_t size, enum dma_data_direction dir,
-struct dma_attrs *attrs)
+unsigned long attrs)
 {
struct scif_hw_dev *scdev = dev_get_drvdata(dev);
struct mic_device *mdev = scdev_to_mdev(scdev);
@@ -198,7 +198,7 @@ __mic_dma_unmap_page(struct device *dev, dma_addr_t 
dma_addr,
 
 static int __mic_dma_map_sg(struct device *dev, struct scatterlist *sg,
int nents, enum dma_data_direction dir,
-   struct dma_attrs *attrs)
+   unsigned long attrs)
 {
struct scif_hw_dev *scdev = dev_get_drvdata(dev);
struct mic_device *mdev = scdev_to_mdev(scdev);
@@ -229,7 +229,7 @@ err:
 static void __mic_dma_unmap_sg(struct device *dev,
   struct scatterlist *sg, int nents,
   enum dma_data_direction dir,
-  struct dma_attrs *attrs)
+  unsigned long attrs)
 {
struct scif_hw_dev *scdev = dev_get_drvdata(dev);
struct mic_device *mdev = scdev_to_mdev(scdev);
@@ -327,7 +327,7 @@ static inline struct mic_device *mbdev_to_mdev(struct 
mbus_device *mbdev)
 static dma_addr_t
 mic_dma_map_page(struct device *dev, struct page *page,
 unsigned long offset, size_t size, enum dma_data_direction dir,
-struct dma_attrs *attrs)
+unsigned long attrs)
 {
void *va = phys_to_virt(page_to_phys(page)) + offset;
struct mic_device *mdev = dev_get_drvdata(dev->parent);
@@ -338,7 +338,7 @@ mic_dma_map_page(struct device *dev, struct page *page,
 static void
 mic_dma_unmap_page(struct device *dev, dma_addr_t dma_addr,
   size_t size, enum dma_data_direction dir,
-  struct dma_attrs *attrs)
+  unsigned long attrs)
 {
struct mic_device *mdev = dev_get_drvdata(dev->parent);
mic_unmap_single(mdev, dma_addr, size);
-- 
1.9.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org

[Xen-devel] [RFC v3 35/45] openrisc: dma-mapping: Use unsigned long for dma_attrs

2016-06-02 Thread Krzysztof Kozlowski
Split out subsystem specific changes for easier reviews. This will be
squashed with main commit.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/openrisc/kernel/dma.c | 17 -
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/arch/openrisc/kernel/dma.c b/arch/openrisc/kernel/dma.c
index 0b77ddb1ee07..50eb1f26c540 100644
--- a/arch/openrisc/kernel/dma.c
+++ b/arch/openrisc/kernel/dma.c
@@ -22,7 +22,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include 
 #include 
@@ -83,7 +82,7 @@ page_clear_nocache(pte_t *pte, unsigned long addr,
 static void *
 or1k_dma_alloc(struct device *dev, size_t size,
   dma_addr_t *dma_handle, gfp_t gfp,
-  struct dma_attrs *attrs)
+  unsigned long attrs)
 {
unsigned long va;
void *page;
@@ -117,7 +116,7 @@ or1k_dma_alloc(struct device *dev, size_t size,
 
 static void
 or1k_dma_free(struct device *dev, size_t size, void *vaddr,
- dma_addr_t dma_handle, struct dma_attrs *attrs)
+ dma_addr_t dma_handle, unsigned long attrs)
 {
unsigned long va = (unsigned long)vaddr;
struct mm_walk walk = {
@@ -137,7 +136,7 @@ static dma_addr_t
 or1k_map_page(struct device *dev, struct page *page,
  unsigned long offset, size_t size,
  enum dma_data_direction dir,
- struct dma_attrs *attrs)
+ unsigned long attrs)
 {
unsigned long cl;
dma_addr_t addr = page_to_phys(page) + offset;
@@ -170,7 +169,7 @@ or1k_map_page(struct device *dev, struct page *page,
 static void
 or1k_unmap_page(struct device *dev, dma_addr_t dma_handle,
size_t size, enum dma_data_direction dir,
-   struct dma_attrs *attrs)
+   unsigned long attrs)
 {
/* Nothing special to do here... */
 }
@@ -178,14 +177,14 @@ or1k_unmap_page(struct device *dev, dma_addr_t dma_handle,
 static int
 or1k_map_sg(struct device *dev, struct scatterlist *sg,
int nents, enum dma_data_direction dir,
-   struct dma_attrs *attrs)
+   unsigned long attrs)
 {
struct scatterlist *s;
int i;
 
for_each_sg(sg, s, nents, i) {
s->dma_address = or1k_map_page(dev, sg_page(s), s->offset,
-  s->length, dir, NULL);
+  s->length, dir, 0);
}
 
return nents;
@@ -194,13 +193,13 @@ or1k_map_sg(struct device *dev, struct scatterlist *sg,
 static void
 or1k_unmap_sg(struct device *dev, struct scatterlist *sg,
  int nents, enum dma_data_direction dir,
- struct dma_attrs *attrs)
+ unsigned long attrs)
 {
struct scatterlist *s;
int i;
 
for_each_sg(sg, s, nents, i) {
-   or1k_unmap_page(dev, sg_dma_address(s), sg_dma_len(s), dir, 
NULL);
+   or1k_unmap_page(dev, sg_dma_address(s), sg_dma_len(s), dir, 0);
}
 }
 
-- 
1.9.1


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


[Xen-devel] [RFC v3 34/45] nios2: dma-mapping: Use unsigned long for dma_attrs

2016-06-02 Thread Krzysztof Kozlowski
Split out subsystem specific changes for easier reviews. This will be
squashed with main commit.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/nios2/mm/dma-mapping.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/nios2/mm/dma-mapping.c b/arch/nios2/mm/dma-mapping.c
index 90422c367ed3..d800fad87896 100644
--- a/arch/nios2/mm/dma-mapping.c
+++ b/arch/nios2/mm/dma-mapping.c
@@ -59,7 +59,7 @@ static inline void __dma_sync_for_cpu(void *vaddr, size_t 
size,
 }
 
 static void *nios2_dma_alloc(struct device *dev, size_t size,
-   dma_addr_t *dma_handle, gfp_t gfp, struct dma_attrs *attrs)
+   dma_addr_t *dma_handle, gfp_t gfp, unsigned long attrs)
 {
void *ret;
 
@@ -84,7 +84,7 @@ static void *nios2_dma_alloc(struct device *dev, size_t size,
 }
 
 static void nios2_dma_free(struct device *dev, size_t size, void *vaddr,
-   dma_addr_t dma_handle, struct dma_attrs *attrs)
+   dma_addr_t dma_handle, unsigned long attrs)
 {
unsigned long addr = (unsigned long) CAC_ADDR((unsigned long) vaddr);
 
@@ -93,7 +93,7 @@ static void nios2_dma_free(struct device *dev, size_t size, 
void *vaddr,
 
 static int nios2_dma_map_sg(struct device *dev, struct scatterlist *sg,
int nents, enum dma_data_direction direction,
-   struct dma_attrs *attrs)
+   unsigned long attrs)
 {
int i;
 
@@ -113,7 +113,7 @@ static int nios2_dma_map_sg(struct device *dev, struct 
scatterlist *sg,
 static dma_addr_t nios2_dma_map_page(struct device *dev, struct page *page,
unsigned long offset, size_t size,
enum dma_data_direction direction,
-   struct dma_attrs *attrs)
+   unsigned long attrs)
 {
void *addr = page_address(page) + offset;
 
@@ -123,14 +123,14 @@ static dma_addr_t nios2_dma_map_page(struct device *dev, 
struct page *page,
 
 static void nios2_dma_unmap_page(struct device *dev, dma_addr_t dma_address,
size_t size, enum dma_data_direction direction,
-   struct dma_attrs *attrs)
+   unsigned long attrs)
 {
__dma_sync_for_cpu(phys_to_virt(dma_address), size, direction);
 }
 
 static void nios2_dma_unmap_sg(struct device *dev, struct scatterlist *sg,
int nhwentries, enum dma_data_direction direction,
-   struct dma_attrs *attrs)
+   unsigned long attrs)
 {
void *addr;
int i;
-- 
1.9.1


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


[Xen-devel] [RFC v3 32/45] mips: dma-mapping: Use unsigned long for dma_attrs

2016-06-02 Thread Krzysztof Kozlowski
Split out subsystem specific changes for easier reviews. This will be
squashed with main commit.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/mips/cavium-octeon/dma-octeon.c  |  8 
 arch/mips/loongson64/common/dma-swiotlb.c | 10 +-
 arch/mips/mm/dma-default.c| 14 +++---
 arch/mips/netlogic/common/nlm-dma.c   |  4 ++--
 4 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/arch/mips/cavium-octeon/dma-octeon.c 
b/arch/mips/cavium-octeon/dma-octeon.c
index 2cd45f5f9481..fd69528b24fb 100644
--- a/arch/mips/cavium-octeon/dma-octeon.c
+++ b/arch/mips/cavium-octeon/dma-octeon.c
@@ -125,7 +125,7 @@ static phys_addr_t octeon_small_dma_to_phys(struct device 
*dev,
 
 static dma_addr_t octeon_dma_map_page(struct device *dev, struct page *page,
unsigned long offset, size_t size, enum dma_data_direction direction,
-   struct dma_attrs *attrs)
+   unsigned long attrs)
 {
dma_addr_t daddr = swiotlb_map_page(dev, page, offset, size,
direction, attrs);
@@ -135,7 +135,7 @@ static dma_addr_t octeon_dma_map_page(struct device *dev, 
struct page *page,
 }
 
 static int octeon_dma_map_sg(struct device *dev, struct scatterlist *sg,
-   int nents, enum dma_data_direction direction, struct dma_attrs *attrs)
+   int nents, enum dma_data_direction direction, unsigned long attrs)
 {
int r = swiotlb_map_sg_attrs(dev, sg, nents, direction, attrs);
mb();
@@ -157,7 +157,7 @@ static void octeon_dma_sync_sg_for_device(struct device 
*dev,
 }
 
 static void *octeon_dma_alloc_coherent(struct device *dev, size_t size,
-   dma_addr_t *dma_handle, gfp_t gfp, struct dma_attrs *attrs)
+   dma_addr_t *dma_handle, gfp_t gfp, unsigned long attrs)
 {
void *ret;
 
@@ -189,7 +189,7 @@ static void *octeon_dma_alloc_coherent(struct device *dev, 
size_t size,
 }
 
 static void octeon_dma_free_coherent(struct device *dev, size_t size,
-   void *vaddr, dma_addr_t dma_handle, struct dma_attrs *attrs)
+   void *vaddr, dma_addr_t dma_handle, unsigned long attrs)
 {
swiotlb_free_coherent(dev, size, vaddr, dma_handle);
 }
diff --git a/arch/mips/loongson64/common/dma-swiotlb.c 
b/arch/mips/loongson64/common/dma-swiotlb.c
index 4ffa6fc81c8f..1a80b6f73ab2 100644
--- a/arch/mips/loongson64/common/dma-swiotlb.c
+++ b/arch/mips/loongson64/common/dma-swiotlb.c
@@ -10,7 +10,7 @@
 #include 
 
 static void *loongson_dma_alloc_coherent(struct device *dev, size_t size,
-   dma_addr_t *dma_handle, gfp_t gfp, struct dma_attrs *attrs)
+   dma_addr_t *dma_handle, gfp_t gfp, unsigned long attrs)
 {
void *ret;
 
@@ -41,7 +41,7 @@ static void *loongson_dma_alloc_coherent(struct device *dev, 
size_t size,
 }
 
 static void loongson_dma_free_coherent(struct device *dev, size_t size,
-   void *vaddr, dma_addr_t dma_handle, struct dma_attrs *attrs)
+   void *vaddr, dma_addr_t dma_handle, unsigned long attrs)
 {
swiotlb_free_coherent(dev, size, vaddr, dma_handle);
 }
@@ -49,7 +49,7 @@ static void loongson_dma_free_coherent(struct device *dev, 
size_t size,
 static dma_addr_t loongson_dma_map_page(struct device *dev, struct page *page,
unsigned long offset, size_t size,
enum dma_data_direction dir,
-   struct dma_attrs *attrs)
+   unsigned long attrs)
 {
dma_addr_t daddr = swiotlb_map_page(dev, page, offset, size,
dir, attrs);
@@ -59,9 +59,9 @@ static dma_addr_t loongson_dma_map_page(struct device *dev, 
struct page *page,
 
 static int loongson_dma_map_sg(struct device *dev, struct scatterlist *sg,
int nents, enum dma_data_direction dir,
-   struct dma_attrs *attrs)
+   unsigned long attrs)
 {
-   int r = swiotlb_map_sg_attrs(dev, sg, nents, dir, NULL);
+   int r = swiotlb_map_sg_attrs(dev, sg, nents, dir, 0);
mb();
 
return r;
diff --git a/arch/mips/mm/dma-default.c b/arch/mips/mm/dma-default.c
index cb557d28cb21..c9052108094f 100644
--- a/arch/mips/mm/dma-default.c
+++ b/arch/mips/mm/dma-default.c
@@ -131,7 +131,7 @@ static void *mips_dma_alloc_noncoherent(struct device *dev, 
size_t size,
 }
 
 static void *mips_dma_alloc_coherent(struct device *dev, size_t size,
-   dma_addr_t * dma_handle, gfp_t gfp, struct dma_attrs *attrs)
+   dma_addr_t * dma_handle, gfp_t gfp, unsigned long attrs)
 {
void *ret;
struct page *page = NULL;
@@ -176,7 +176,7 @@ static void mips_dma_free_noncoherent(struct device *dev, 
size_t size,
 }
 
 static void mips_dma_free_coherent(struct device *dev, size_t size, void 
*vaddr,
-   dma_addr_t dma_handle, struct dma_attrs *attrs)
+   dma_addr_t dma_handle, unsigned long attrs)
 {

[Xen-devel] [RFC v3 30/45] metag: dma-mapping: Use unsigned long for dma_attrs

2016-06-02 Thread Krzysztof Kozlowski
Split out subsystem specific changes for easier reviews. This will be
squashed with main commit.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/metag/kernel/dma.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/metag/kernel/dma.c b/arch/metag/kernel/dma.c
index e12368d02155..d68f498e82a1 100644
--- a/arch/metag/kernel/dma.c
+++ b/arch/metag/kernel/dma.c
@@ -172,7 +172,7 @@ out:
  * virtual and bus address for that space.
  */
 static void *metag_dma_alloc(struct device *dev, size_t size,
-   dma_addr_t *handle, gfp_t gfp, struct dma_attrs *attrs)
+   dma_addr_t *handle, gfp_t gfp, unsigned long attrs)
 {
struct page *page;
struct metag_vm_region *c;
@@ -268,7 +268,7 @@ no_page:
  * free a page as defined by the above mapping.
  */
 static void metag_dma_free(struct device *dev, size_t size, void *vaddr,
-   dma_addr_t dma_handle, struct dma_attrs *attrs)
+   dma_addr_t dma_handle, unsigned long attrs)
 {
struct metag_vm_region *c;
unsigned long flags, addr;
@@ -331,7 +331,7 @@ no_area:
 
 static int metag_dma_mmap(struct device *dev, struct vm_area_struct *vma,
void *cpu_addr, dma_addr_t dma_addr, size_t size,
-   struct dma_attrs *attrs)
+   unsigned long attrs)
 {
unsigned long flags, user_size, kern_size;
struct metag_vm_region *c;
@@ -482,7 +482,7 @@ static void dma_sync_for_cpu(void *vaddr, size_t size, int 
dma_direction)
 
 static dma_addr_t metag_dma_map_page(struct device *dev, struct page *page,
unsigned long offset, size_t size,
-   enum dma_data_direction direction, struct dma_attrs *attrs)
+   enum dma_data_direction direction, unsigned long attrs)
 {
dma_sync_for_device((void *)(page_to_phys(page) + offset), size,
direction);
@@ -491,14 +491,14 @@ static dma_addr_t metag_dma_map_page(struct device *dev, 
struct page *page,
 
 static void metag_dma_unmap_page(struct device *dev, dma_addr_t dma_address,
size_t size, enum dma_data_direction direction,
-   struct dma_attrs *attrs)
+   unsigned long attrs)
 {
dma_sync_for_cpu(phys_to_virt(dma_address), size, direction);
 }
 
 static int metag_dma_map_sg(struct device *dev, struct scatterlist *sglist,
int nents, enum dma_data_direction direction,
-   struct dma_attrs *attrs)
+   unsigned long attrs)
 {
struct scatterlist *sg;
int i;
@@ -516,7 +516,7 @@ static int metag_dma_map_sg(struct device *dev, struct 
scatterlist *sglist,
 
 static void metag_dma_unmap_sg(struct device *dev, struct scatterlist *sglist,
int nhwentries, enum dma_data_direction direction,
-   struct dma_attrs *attrs)
+   unsigned long attrs)
 {
struct scatterlist *sg;
int i;
-- 
1.9.1


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


[Xen-devel] [RFC v3 33/45] mn10300: dma-mapping: Use unsigned long for dma_attrs

2016-06-02 Thread Krzysztof Kozlowski
Split out subsystem specific changes for easier reviews. This will be
squashed with main commit.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/mn10300/mm/dma-alloc.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/mn10300/mm/dma-alloc.c b/arch/mn10300/mm/dma-alloc.c
index 8842394cb49a..4f4b9029f0ea 100644
--- a/arch/mn10300/mm/dma-alloc.c
+++ b/arch/mn10300/mm/dma-alloc.c
@@ -21,7 +21,7 @@
 static unsigned long pci_sram_allocated = 0xbc00;
 
 static void *mn10300_dma_alloc(struct device *dev, size_t size,
-   dma_addr_t *dma_handle, gfp_t gfp, struct dma_attrs *attrs)
+   dma_addr_t *dma_handle, gfp_t gfp, unsigned long attrs)
 {
unsigned long addr;
void *ret;
@@ -63,7 +63,7 @@ done:
 }
 
 static void mn10300_dma_free(struct device *dev, size_t size, void *vaddr,
-   dma_addr_t dma_handle, struct dma_attrs *attrs)
+   dma_addr_t dma_handle, unsigned long attrs)
 {
unsigned long addr = (unsigned long) vaddr & ~0x2000;
 
@@ -75,7 +75,7 @@ static void mn10300_dma_free(struct device *dev, size_t size, 
void *vaddr,
 
 static int mn10300_dma_map_sg(struct device *dev, struct scatterlist *sglist,
int nents, enum dma_data_direction direction,
-   struct dma_attrs *attrs)
+   unsigned long attrs)
 {
struct scatterlist *sg;
int i;
@@ -92,7 +92,7 @@ static int mn10300_dma_map_sg(struct device *dev, struct 
scatterlist *sglist,
 
 static dma_addr_t mn10300_dma_map_page(struct device *dev, struct page *page,
unsigned long offset, size_t size,
-   enum dma_data_direction direction, struct dma_attrs *attrs)
+   enum dma_data_direction direction, unsigned long attrs)
 {
return page_to_bus(page) + offset;
 }
-- 
1.9.1


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


[Xen-devel] [RFC v3 26/45] h8300: dma-mapping: Use unsigned long for dma_attrs

2016-06-02 Thread Krzysztof Kozlowski
Split out subsystem specific changes for easier reviews. This will be
squashed with main commit.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/h8300/kernel/dma.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/h8300/kernel/dma.c b/arch/h8300/kernel/dma.c
index eeb13d3f2424..3651da045806 100644
--- a/arch/h8300/kernel/dma.c
+++ b/arch/h8300/kernel/dma.c
@@ -12,7 +12,7 @@
 
 static void *dma_alloc(struct device *dev, size_t size,
   dma_addr_t *dma_handle, gfp_t gfp,
-  struct dma_attrs *attrs)
+  unsigned long attrs)
 {
void *ret;
 
@@ -32,7 +32,7 @@ static void *dma_alloc(struct device *dev, size_t size,
 
 static void dma_free(struct device *dev, size_t size,
 void *vaddr, dma_addr_t dma_handle,
-struct dma_attrs *attrs)
+unsigned long attrs)
 
 {
free_pages((unsigned long)vaddr, get_order(size));
@@ -41,14 +41,14 @@ static void dma_free(struct device *dev, size_t size,
 static dma_addr_t map_page(struct device *dev, struct page *page,
  unsigned long offset, size_t size,
  enum dma_data_direction direction,
- struct dma_attrs *attrs)
+ unsigned long attrs)
 {
return page_to_phys(page) + offset;
 }
 
 static int map_sg(struct device *dev, struct scatterlist *sgl,
  int nents, enum dma_data_direction direction,
- struct dma_attrs *attrs)
+ unsigned long attrs)
 {
struct scatterlist *sg;
int i;
-- 
1.9.1


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


[Xen-devel] [xen-unstable test] 95174: regressions - FAIL

2016-06-02 Thread osstest service owner
flight 95174 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95174/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 5 xen-install fail REGR. vs. 
95129

Regressions which are regarded as allowable (not blocking):
 build-amd64-rumpuserxen   6 xen-buildfail   like 95129
 build-i386-rumpuserxen6 xen-buildfail   like 95129
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 95129
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 95129
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 95129
 test-amd64-amd64-xl-rtds  9 debian-install   fail   like 95129
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 95129

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-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  7e81d992b183c47a74eea5ecd613d27950b5cdc3
baseline version:
 xen  bbfd2d6ccb31a3aeea49c8f9c7884792ddc26e3b

Last test of basis95129  2016-06-01 11:11:52 Z1 days
Testing same since95174  2016-06-01 21:43:56 Z0 days1 attempts


People who touched revisions under test:
  Ian Jackson 
  Julien Grall 
  Stefano Stabellini 
  Vitaly Kuznetsov 
  Wei Chen 
  Wei Liu 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt   

[Xen-devel] [RFC v3 24/45] x86: dma-mapping: Use unsigned long for dma_attrs

2016-06-02 Thread Krzysztof Kozlowski
Split out subsystem specific changes for easier reviews. This will be
squashed with main commit.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/x86/include/asm/dma-mapping.h   |  5 ++---
 arch/x86/include/asm/swiotlb.h   |  4 ++--
 arch/x86/include/asm/xen/page-coherent.h |  9 -
 arch/x86/kernel/amd_gart_64.c| 20 ++--
 arch/x86/kernel/pci-calgary_64.c | 14 +++---
 arch/x86/kernel/pci-dma.c|  4 ++--
 arch/x86/kernel/pci-nommu.c  |  4 ++--
 arch/x86/kernel/pci-swiotlb.c|  4 ++--
 arch/x86/pci/sta2x11-fixup.c |  2 +-
 arch/x86/pci/vmd.c   | 16 
 10 files changed, 40 insertions(+), 42 deletions(-)

diff --git a/arch/x86/include/asm/dma-mapping.h 
b/arch/x86/include/asm/dma-mapping.h
index 3a27b93e6261..44461626830e 100644
--- a/arch/x86/include/asm/dma-mapping.h
+++ b/arch/x86/include/asm/dma-mapping.h
@@ -9,7 +9,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -48,11 +47,11 @@ extern int dma_supported(struct device *hwdev, u64 mask);
 
 extern void *dma_generic_alloc_coherent(struct device *dev, size_t size,
dma_addr_t *dma_addr, gfp_t flag,
-   struct dma_attrs *attrs);
+   unsigned long attrs);
 
 extern void dma_generic_free_coherent(struct device *dev, size_t size,
  void *vaddr, dma_addr_t dma_addr,
- struct dma_attrs *attrs);
+ unsigned long attrs);
 
 #ifdef CONFIG_X86_DMA_REMAP /* Platform code defines bridge-specific code */
 extern bool dma_capable(struct device *dev, dma_addr_t addr, size_t size);
diff --git a/arch/x86/include/asm/swiotlb.h b/arch/x86/include/asm/swiotlb.h
index ab05d73e2bb7..d2f69b9ff732 100644
--- a/arch/x86/include/asm/swiotlb.h
+++ b/arch/x86/include/asm/swiotlb.h
@@ -31,9 +31,9 @@ static inline void dma_mark_clean(void *addr, size_t size) {}
 
 extern void *x86_swiotlb_alloc_coherent(struct device *hwdev, size_t size,
dma_addr_t *dma_handle, gfp_t flags,
-   struct dma_attrs *attrs);
+   unsigned long attrs);
 extern void x86_swiotlb_free_coherent(struct device *dev, size_t size,
void *vaddr, dma_addr_t dma_addr,
-   struct dma_attrs *attrs);
+   unsigned long attrs);
 
 #endif /* _ASM_X86_SWIOTLB_H */
diff --git a/arch/x86/include/asm/xen/page-coherent.h 
b/arch/x86/include/asm/xen/page-coherent.h
index acd844c017d3..f02f025ff988 100644
--- a/arch/x86/include/asm/xen/page-coherent.h
+++ b/arch/x86/include/asm/xen/page-coherent.h
@@ -2,12 +2,11 @@
 #define _ASM_X86_XEN_PAGE_COHERENT_H
 
 #include 
-#include 
 #include 
 
 static inline void *xen_alloc_coherent_pages(struct device *hwdev, size_t size,
dma_addr_t *dma_handle, gfp_t flags,
-   struct dma_attrs *attrs)
+   unsigned long attrs)
 {
void *vstart = (void*)__get_free_pages(flags, get_order(size));
*dma_handle = virt_to_phys(vstart);
@@ -16,18 +15,18 @@ static inline void *xen_alloc_coherent_pages(struct device 
*hwdev, size_t size,
 
 static inline void xen_free_coherent_pages(struct device *hwdev, size_t size,
void *cpu_addr, dma_addr_t dma_handle,
-   struct dma_attrs *attrs)
+   unsigned long attrs)
 {
free_pages((unsigned long) cpu_addr, get_order(size));
 }
 
 static inline void xen_dma_map_page(struct device *hwdev, struct page *page,
 dma_addr_t dev_addr, unsigned long offset, size_t size,
-enum dma_data_direction dir, struct dma_attrs *attrs) { }
+enum dma_data_direction dir, unsigned long attrs) { }
 
 static inline void xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
size_t size, enum dma_data_direction dir,
-   struct dma_attrs *attrs) { }
+   unsigned long attrs) { }
 
 static inline void xen_dma_sync_single_for_cpu(struct device *hwdev,
dma_addr_t handle, size_t size, enum dma_data_direction dir) { }
diff --git a/arch/x86/kernel/amd_gart_64.c b/arch/x86/kernel/amd_gart_64.c
index 8e3842fc8bea..4aff288e37a4 100644
--- a/arch/x86/kernel/amd_gart_64.c
+++ b/arch/x86/kernel/amd_gart_64.c
@@ -242,7 +242,7 @@ static dma_addr_t dma_map_area(struct device *dev, 
dma_addr_t phys_mem,
 static dma_addr_t gart_map_page(struct device *dev, struct page *page,
unsigned long offset, size_t size,
enum dma_data_direction dir,
-   struct dma_attrs *attrs)
+  

[Xen-devel] [RFC v3 25/45] iommu: intel: dma-mapping: Use unsigned long for dma_attrs

2016-06-02 Thread Krzysztof Kozlowski
Split out subsystem specific changes for easier reviews. This will be
squashed with main commit.

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/iommu/intel-iommu.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index a644d0cec2d8..ba9d28acbf3a 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -3545,7 +3545,7 @@ error:
 static dma_addr_t intel_map_page(struct device *dev, struct page *page,
 unsigned long offset, size_t size,
 enum dma_data_direction dir,
-struct dma_attrs *attrs)
+unsigned long attrs)
 {
return __intel_map_single(dev, page_to_phys(page) + offset, size,
  dir, *dev->dma_mask);
@@ -3704,14 +3704,14 @@ static void intel_unmap(struct device *dev, dma_addr_t 
dev_addr, size_t size)
 
 static void intel_unmap_page(struct device *dev, dma_addr_t dev_addr,
 size_t size, enum dma_data_direction dir,
-struct dma_attrs *attrs)
+unsigned long attrs)
 {
intel_unmap(dev, dev_addr, size);
 }
 
 static void *intel_alloc_coherent(struct device *dev, size_t size,
  dma_addr_t *dma_handle, gfp_t flags,
- struct dma_attrs *attrs)
+ unsigned long attrs)
 {
struct page *page = NULL;
int order;
@@ -3757,7 +3757,7 @@ static void *intel_alloc_coherent(struct device *dev, 
size_t size,
 }
 
 static void intel_free_coherent(struct device *dev, size_t size, void *vaddr,
-   dma_addr_t dma_handle, struct dma_attrs *attrs)
+   dma_addr_t dma_handle, unsigned long attrs)
 {
int order;
struct page *page = virt_to_page(vaddr);
@@ -3772,7 +3772,7 @@ static void intel_free_coherent(struct device *dev, 
size_t size, void *vaddr,
 
 static void intel_unmap_sg(struct device *dev, struct scatterlist *sglist,
   int nelems, enum dma_data_direction dir,
-  struct dma_attrs *attrs)
+  unsigned long attrs)
 {
dma_addr_t startaddr = sg_dma_address(sglist) & PAGE_MASK;
unsigned long nrpages = 0;
@@ -3801,7 +3801,7 @@ static int intel_nontranslate_map_sg(struct device *hddev,
 }
 
 static int intel_map_sg(struct device *dev, struct scatterlist *sglist, int 
nelems,
-   enum dma_data_direction dir, struct dma_attrs *attrs)
+   enum dma_data_direction dir, unsigned long attrs)
 {
int i;
struct dmar_domain *domain;
-- 
1.9.1


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


[Xen-devel] [RFC v3 09/45] c6x: dma-mapping: Use unsigned long for dma_attrs

2016-06-02 Thread Krzysztof Kozlowski
Split out subsystem specific changes for easier reviews. This will be
squashed with main commit.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/c6x/include/asm/dma-mapping.h | 4 ++--
 arch/c6x/kernel/dma.c  | 9 -
 arch/c6x/mm/dma-coherent.c | 4 ++--
 3 files changed, 8 insertions(+), 9 deletions(-)

diff --git a/arch/c6x/include/asm/dma-mapping.h 
b/arch/c6x/include/asm/dma-mapping.h
index 6b5cd7b0cf32..5717b1e52d96 100644
--- a/arch/c6x/include/asm/dma-mapping.h
+++ b/arch/c6x/include/asm/dma-mapping.h
@@ -26,8 +26,8 @@ static inline struct dma_map_ops *get_dma_ops(struct device 
*dev)
 
 extern void coherent_mem_init(u32 start, u32 size);
 void *c6x_dma_alloc(struct device *dev, size_t size, dma_addr_t *handle,
-   gfp_t gfp, struct dma_attrs *attrs);
+   gfp_t gfp, unsigned long attrs);
 void c6x_dma_free(struct device *dev, size_t size, void *vaddr,
-   dma_addr_t dma_handle, struct dma_attrs *attrs);
+   dma_addr_t dma_handle, unsigned long attrs);
 
 #endif /* _ASM_C6X_DMA_MAPPING_H */
diff --git a/arch/c6x/kernel/dma.c b/arch/c6x/kernel/dma.c
index 8a80f3a250c0..db4a6a301f5e 100644
--- a/arch/c6x/kernel/dma.c
+++ b/arch/c6x/kernel/dma.c
@@ -38,7 +38,7 @@ static void c6x_dma_sync(dma_addr_t handle, size_t size,
 
 static dma_addr_t c6x_dma_map_page(struct device *dev, struct page *page,
unsigned long offset, size_t size, enum dma_data_direction dir,
-   struct dma_attrs *attrs)
+   unsigned long attrs)
 {
dma_addr_t handle = virt_to_phys(page_address(page) + offset);
 
@@ -47,13 +47,13 @@ static dma_addr_t c6x_dma_map_page(struct device *dev, 
struct page *page,
 }
 
 static void c6x_dma_unmap_page(struct device *dev, dma_addr_t handle,
-   size_t size, enum dma_data_direction dir, struct dma_attrs 
*attrs)
+   size_t size, enum dma_data_direction dir, unsigned long attrs)
 {
c6x_dma_sync(handle, size, dir);
 }
 
 static int c6x_dma_map_sg(struct device *dev, struct scatterlist *sglist,
-   int nents, enum dma_data_direction dir, struct dma_attrs *attrs)
+   int nents, enum dma_data_direction dir, unsigned long attrs)
 {
struct scatterlist *sg;
int i;
@@ -67,8 +67,7 @@ static int c6x_dma_map_sg(struct device *dev, struct 
scatterlist *sglist,
 }
 
 static void c6x_dma_unmap_sg(struct device *dev, struct scatterlist *sglist,
- int nents, enum dma_data_direction dir,
- struct dma_attrs *attrs)
+ int nents, enum dma_data_direction dir, unsigned long attrs)
 {
struct scatterlist *sg;
int i;
diff --git a/arch/c6x/mm/dma-coherent.c b/arch/c6x/mm/dma-coherent.c
index f7ee63af2541..95e38ad27c69 100644
--- a/arch/c6x/mm/dma-coherent.c
+++ b/arch/c6x/mm/dma-coherent.c
@@ -74,7 +74,7 @@ static void __free_dma_pages(u32 addr, int order)
  * virtual and DMA address for that space.
  */
 void *c6x_dma_alloc(struct device *dev, size_t size, dma_addr_t *handle,
-   gfp_t gfp, struct dma_attrs *attrs)
+   gfp_t gfp, unsigned long attrs)
 {
u32 paddr;
int order;
@@ -99,7 +99,7 @@ void *c6x_dma_alloc(struct device *dev, size_t size, 
dma_addr_t *handle,
  * Free DMA coherent memory as defined by the above mapping.
  */
 void c6x_dma_free(struct device *dev, size_t size, void *vaddr,
-   dma_addr_t dma_handle, struct dma_attrs *attrs)
+   dma_addr_t dma_handle, unsigned long attrs)
 {
int order;
 
-- 
1.9.1


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


[Xen-devel] [RFC v3 28/45] ia64: dma-mapping: Use unsigned long for dma_attrs

2016-06-02 Thread Krzysztof Kozlowski
Split out subsystem specific changes for easier reviews. This will be
squashed with main commit.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/ia64/hp/common/sba_iommu.c | 22 +++---
 arch/ia64/include/asm/machvec.h |  1 -
 arch/ia64/kernel/pci-swiotlb.c  |  4 ++--
 arch/ia64/sn/pci/pci_dma.c  | 12 ++--
 4 files changed, 19 insertions(+), 20 deletions(-)

diff --git a/arch/ia64/hp/common/sba_iommu.c b/arch/ia64/hp/common/sba_iommu.c
index a6d6190c9d24..630ee8073899 100644
--- a/arch/ia64/hp/common/sba_iommu.c
+++ b/arch/ia64/hp/common/sba_iommu.c
@@ -919,7 +919,7 @@ sba_mark_invalid(struct ioc *ioc, dma_addr_t iova, size_t 
byte_cnt)
 static dma_addr_t sba_map_page(struct device *dev, struct page *page,
   unsigned long poff, size_t size,
   enum dma_data_direction dir,
-  struct dma_attrs *attrs)
+  unsigned long attrs)
 {
struct ioc *ioc;
void *addr = page_address(page) + poff;
@@ -1005,7 +1005,7 @@ static dma_addr_t sba_map_page(struct device *dev, struct 
page *page,
 
 static dma_addr_t sba_map_single_attrs(struct device *dev, void *addr,
   size_t size, enum dma_data_direction dir,
-  struct dma_attrs *attrs)
+  unsigned long attrs)
 {
return sba_map_page(dev, virt_to_page(addr),
(unsigned long)addr & ~PAGE_MASK, size, dir, attrs);
@@ -1046,7 +1046,7 @@ sba_mark_clean(struct ioc *ioc, dma_addr_t iova, size_t 
size)
  * See Documentation/DMA-API-HOWTO.txt
  */
 static void sba_unmap_page(struct device *dev, dma_addr_t iova, size_t size,
-  enum dma_data_direction dir, struct dma_attrs *attrs)
+  enum dma_data_direction dir, unsigned long attrs)
 {
struct ioc *ioc;
 #if DELAYED_RESOURCE_CNT > 0
@@ -1115,7 +1115,7 @@ static void sba_unmap_page(struct device *dev, dma_addr_t 
iova, size_t size,
 }
 
 void sba_unmap_single_attrs(struct device *dev, dma_addr_t iova, size_t size,
-   enum dma_data_direction dir, struct dma_attrs 
*attrs)
+   enum dma_data_direction dir, unsigned long attrs)
 {
sba_unmap_page(dev, iova, size, dir, attrs);
 }
@@ -1130,7 +1130,7 @@ void sba_unmap_single_attrs(struct device *dev, 
dma_addr_t iova, size_t size,
  */
 static void *
 sba_alloc_coherent(struct device *dev, size_t size, dma_addr_t *dma_handle,
-  gfp_t flags, struct dma_attrs *attrs)
+  gfp_t flags, unsigned long attrs)
 {
struct ioc *ioc;
void *addr;
@@ -1175,7 +1175,7 @@ sba_alloc_coherent(struct device *dev, size_t size, 
dma_addr_t *dma_handle,
 * device to map single to get an iova mapping.
 */
*dma_handle = sba_map_single_attrs(>sac_only_dev->dev, addr,
-  size, 0, NULL);
+  size, 0, 0);
 
return addr;
 }
@@ -1191,9 +1191,9 @@ sba_alloc_coherent(struct device *dev, size_t size, 
dma_addr_t *dma_handle,
  * See Documentation/DMA-API-HOWTO.txt
  */
 static void sba_free_coherent(struct device *dev, size_t size, void *vaddr,
- dma_addr_t dma_handle, struct dma_attrs *attrs)
+ dma_addr_t dma_handle, unsigned long attrs)
 {
-   sba_unmap_single_attrs(dev, dma_handle, size, 0, NULL);
+   sba_unmap_single_attrs(dev, dma_handle, size, 0, 0);
free_pages((unsigned long) vaddr, get_order(size));
 }
 
@@ -1442,7 +1442,7 @@ sba_coalesce_chunks(struct ioc *ioc, struct device *dev,
 
 static void sba_unmap_sg_attrs(struct device *dev, struct scatterlist *sglist,
   int nents, enum dma_data_direction dir,
-  struct dma_attrs *attrs);
+  unsigned long attrs);
 /**
  * sba_map_sg - map Scatter/Gather list
  * @dev: instance of PCI owned by the driver that's asking.
@@ -1455,7 +1455,7 @@ static void sba_unmap_sg_attrs(struct device *dev, struct 
scatterlist *sglist,
  */
 static int sba_map_sg_attrs(struct device *dev, struct scatterlist *sglist,
int nents, enum dma_data_direction dir,
-   struct dma_attrs *attrs)
+   unsigned long attrs)
 {
struct ioc *ioc;
int coalesced, filled = 0;
@@ -1551,7 +1551,7 @@ static int sba_map_sg_attrs(struct device *dev, struct 
scatterlist *sglist,
  */
 static void sba_unmap_sg_attrs(struct device *dev, struct scatterlist *sglist,
   int nents, enum dma_data_direction dir,
-  struct dma_attrs *attrs)
+  unsigned long attrs)
 {
 #ifdef ASSERT_PDIR_SANITY
struct ioc *ioc;
diff 

[Xen-devel] [RFC v3 19/45] [media] dma-mapping: Use unsigned long for dma_attrs

2016-06-02 Thread Krzysztof Kozlowski
Split out subsystem specific changes for easier reviews. This will be
squashed with main commit.

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/media/platform/sti/bdisp/bdisp-hw.c| 26 +++---
 drivers/media/v4l2-core/videobuf2-dma-contig.c | 30 +++---
 drivers/media/v4l2-core/videobuf2-dma-sg.c | 19 
 include/media/videobuf2-dma-contig.h   |  7 ++
 4 files changed, 26 insertions(+), 56 deletions(-)

diff --git a/drivers/media/platform/sti/bdisp/bdisp-hw.c 
b/drivers/media/platform/sti/bdisp/bdisp-hw.c
index 052c932ac942..1600958939a5 100644
--- a/drivers/media/platform/sti/bdisp/bdisp-hw.c
+++ b/drivers/media/platform/sti/bdisp/bdisp-hw.c
@@ -125,14 +125,11 @@ int bdisp_hw_get_and_clear_irq(struct bdisp_dev *bdisp)
  */
 void bdisp_hw_free_nodes(struct bdisp_ctx *ctx)
 {
-   if (ctx && ctx->node[0]) {
-   DEFINE_DMA_ATTRS(attrs);
-
-   dma_set_attr(DMA_ATTR_WRITE_COMBINE, );
+   if (ctx && ctx->node[0])
dma_free_attrs(ctx->bdisp_dev->dev,
   sizeof(struct bdisp_node) * MAX_NB_NODE,
-  ctx->node[0], ctx->node_paddr[0], );
-   }
+  ctx->node[0], ctx->node_paddr[0],
+  DMA_ATTR_WRITE_COMBINE);
 }
 
 /**
@@ -150,12 +147,10 @@ int bdisp_hw_alloc_nodes(struct bdisp_ctx *ctx)
unsigned int i, node_size = sizeof(struct bdisp_node);
void *base;
dma_addr_t paddr;
-   DEFINE_DMA_ATTRS(attrs);
 
/* Allocate all the nodes within a single memory page */
-   dma_set_attr(DMA_ATTR_WRITE_COMBINE, );
base = dma_alloc_attrs(dev, node_size * MAX_NB_NODE, ,
-  GFP_KERNEL | GFP_DMA, );
+  GFP_KERNEL | GFP_DMA, DMA_ATTR_WRITE_COMBINE);
if (!base) {
dev_err(dev, "%s no mem\n", __func__);
return -ENOMEM;
@@ -188,13 +183,9 @@ void bdisp_hw_free_filters(struct device *dev)
 {
int size = (BDISP_HF_NB * NB_H_FILTER) + (BDISP_VF_NB * NB_V_FILTER);
 
-   if (bdisp_h_filter[0].virt) {
-   DEFINE_DMA_ATTRS(attrs);
-
-   dma_set_attr(DMA_ATTR_WRITE_COMBINE, );
+   if (bdisp_h_filter[0].virt)
dma_free_attrs(dev, size, bdisp_h_filter[0].virt,
-  bdisp_h_filter[0].paddr, );
-   }
+  bdisp_h_filter[0].paddr,DMA_ATTR_WRITE_COMBINE);
 }
 
 /**
@@ -211,12 +202,11 @@ int bdisp_hw_alloc_filters(struct device *dev)
unsigned int i, size;
void *base;
dma_addr_t paddr;
-   DEFINE_DMA_ATTRS(attrs);
 
/* Allocate all the filters within a single memory page */
size = (BDISP_HF_NB * NB_H_FILTER) + (BDISP_VF_NB * NB_V_FILTER);
-   dma_set_attr(DMA_ATTR_WRITE_COMBINE, );
-   base = dma_alloc_attrs(dev, size, , GFP_KERNEL | GFP_DMA, );
+   base = dma_alloc_attrs(dev, size, , GFP_KERNEL | GFP_DMA,
+  DMA_ATTR_WRITE_COMBINE);
if (!base)
return -ENOMEM;
 
diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c 
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index 5361197f3e57..8009a582326b 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -23,7 +23,7 @@
 
 struct vb2_dc_conf {
struct device   *dev;
-   struct dma_attrsattrs;
+   unsigned long   attrs;
 };
 
 struct vb2_dc_buf {
@@ -32,7 +32,7 @@ struct vb2_dc_buf {
unsigned long   size;
void*cookie;
dma_addr_t  dma_addr;
-   struct dma_attrsattrs;
+   unsigned long   attrs;
enum dma_data_direction dma_dir;
struct sg_table *dma_sgt;
struct frame_vector *vec;
@@ -135,7 +135,7 @@ static void vb2_dc_put(void *buf_priv)
kfree(buf->sgt_base);
}
dma_free_attrs(buf->dev, buf->size, buf->cookie, buf->dma_addr,
-   >attrs);
+  buf->attrs);
put_device(buf->dev);
kfree(buf);
 }
@@ -153,14 +153,14 @@ static void *vb2_dc_alloc(void *alloc_ctx, unsigned long 
size,
 
buf->attrs = conf->attrs;
buf->cookie = dma_alloc_attrs(dev, size, >dma_addr,
-   GFP_KERNEL | gfp_flags, >attrs);
+   GFP_KERNEL | gfp_flags, buf->attrs);
if (!buf->cookie) {
dev_err(dev, "dma_alloc_coherent of size %ld failed\n", size);
kfree(buf);
return ERR_PTR(-ENOMEM);
}
 
-   if (!dma_get_attr(DMA_ATTR_NO_KERNEL_MAPPING, >attrs))
+   if (!dma_get_attr(DMA_ATTR_NO_KERNEL_MAPPING, buf->attrs))
  

[Xen-devel] [RFC v3 14/45] drm/msm: dma-mapping: Use unsigned long for dma_attrs

2016-06-02 Thread Krzysztof Kozlowski
Split out subsystem specific changes for easier reviews. This will be
squashed with main commit.

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/gpu/drm/msm/msm_drv.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 1f7de47d817e..9b806e576d35 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -230,11 +230,10 @@ static int msm_drm_uninit(struct device *dev)
}
 
if (priv->vram.paddr) {
-   DEFINE_DMA_ATTRS(attrs);
-   dma_set_attr(DMA_ATTR_NO_KERNEL_MAPPING, );
+   unsigned long attrs = DMA_ATTR_NO_KERNEL_MAPPING;
drm_mm_takedown(>vram.mm);
dma_free_attrs(dev, priv->vram.size, NULL,
-  priv->vram.paddr, );
+  priv->vram.paddr, attrs);
}
 
component_unbind_all(dev, ddev);
@@ -299,21 +298,21 @@ static int msm_init_vram(struct drm_device *dev)
}
 
if (size) {
-   DEFINE_DMA_ATTRS(attrs);
+   unsigned long attrs = 0;
void *p;
 
priv->vram.size = size;
 
drm_mm_init(>vram.mm, 0, (size >> PAGE_SHIFT) - 1);
 
-   dma_set_attr(DMA_ATTR_NO_KERNEL_MAPPING, );
-   dma_set_attr(DMA_ATTR_WRITE_COMBINE, );
+   attrs |= DMA_ATTR_NO_KERNEL_MAPPING;
+   attrs |= DMA_ATTR_WRITE_COMBINE;
 
/* note that for no-kernel-mapping, the vaddr returned
 * is bogus, but non-null if allocation succeeded:
 */
p = dma_alloc_attrs(dev->dev, size,
-   >vram.paddr, GFP_KERNEL, );
+   >vram.paddr, GFP_KERNEL, attrs);
if (!p) {
dev_err(dev->dev, "failed to allocate VRAM\n");
priv->vram.paddr = 0;
-- 
1.9.1


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


[Xen-devel] [RFC v3 10/45] cris: dma-mapping: Use unsigned long for dma_attrs

2016-06-02 Thread Krzysztof Kozlowski
Split out subsystem specific changes for easier reviews. This will be
squashed with main commit.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/cris/arch-v32/drivers/pci/dma.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/arch/cris/arch-v32/drivers/pci/dma.c 
b/arch/cris/arch-v32/drivers/pci/dma.c
index 8d5efa58cce1..1f0636793f0c 100644
--- a/arch/cris/arch-v32/drivers/pci/dma.c
+++ b/arch/cris/arch-v32/drivers/pci/dma.c
@@ -17,7 +17,7 @@
 #include 
 
 static void *v32_dma_alloc(struct device *dev, size_t size,
-   dma_addr_t *dma_handle, gfp_t gfp,  struct dma_attrs *attrs)
+   dma_addr_t *dma_handle, gfp_t gfp, unsigned long attrs)
 {
void *ret;
 
@@ -37,22 +37,21 @@ static void *v32_dma_alloc(struct device *dev, size_t size,
 }
 
 static void v32_dma_free(struct device *dev, size_t size, void *vaddr,
-   dma_addr_t dma_handle, struct dma_attrs *attrs)
+   dma_addr_t dma_handle, unsigned long attrs)
 {
free_pages((unsigned long)vaddr, get_order(size));
 }
 
 static inline dma_addr_t v32_dma_map_page(struct device *dev,
struct page *page, unsigned long offset, size_t size,
-   enum dma_data_direction direction,
-   struct dma_attrs *attrs)
+   enum dma_data_direction direction, unsigned long attrs)
 {
return page_to_phys(page) + offset;
 }
 
 static inline int v32_dma_map_sg(struct device *dev, struct scatterlist *sg,
int nents, enum dma_data_direction direction,
-   struct dma_attrs *attrs)
+   unsigned long attrs)
 {
printk("Map sg\n");
return nents;
-- 
1.9.1


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


[Xen-devel] [RFC v3 15/45] drm/nouveau: dma-mapping: Use unsigned long for dma_attrs

2016-06-02 Thread Krzysztof Kozlowski
Split out subsystem specific changes for easier reviews. This will be
squashed with main commit.

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c
index 6b8f2a19b2d9..a6a7fa0d7679 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c
@@ -109,7 +109,7 @@ struct gk20a_instmem {
u16 iommu_bit;
 
/* Only used by DMA API */
-   struct dma_attrs attrs;
+   unsigned long attrs;
 };
 #define gk20a_instmem(p) container_of((p), struct gk20a_instmem, base)
 
@@ -293,7 +293,7 @@ gk20a_instobj_dtor_dma(struct nvkm_memory *memory)
goto out;
 
dma_free_attrs(dev, node->base.mem.size << PAGE_SHIFT, node->base.vaddr,
-  node->handle, >attrs);
+  node->handle, imem->attrs);
 
 out:
return node;
@@ -386,7 +386,7 @@ gk20a_instobj_ctor_dma(struct gk20a_instmem *imem, u32 
npages, u32 align,
 
node->base.vaddr = dma_alloc_attrs(dev, npages << PAGE_SHIFT,
   >handle, GFP_KERNEL,
-  >attrs);
+  imem->attrs);
if (!node->base.vaddr) {
nvkm_error(subdev, "cannot allocate DMA memory\n");
return -ENOMEM;
@@ -597,10 +597,9 @@ gk20a_instmem_new(struct nvkm_device *device, int index,
 
nvkm_info(>base.subdev, "using IOMMU\n");
} else {
-   init_dma_attrs(>attrs);
-   dma_set_attr(DMA_ATTR_NON_CONSISTENT, >attrs);
-   dma_set_attr(DMA_ATTR_WEAK_ORDERING, >attrs);
-   dma_set_attr(DMA_ATTR_WRITE_COMBINE, >attrs);
+   imem->attrs = DMA_ATTR_NON_CONSISTENT |
+ DMA_ATTR_WEAK_ORDERING |
+ DMA_ATTR_WRITE_COMBINE;
 
nvkm_info(>base.subdev, "using DMA API\n");
}
-- 
1.9.1


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


[Xen-devel] [RFC v3 23/45] video: dma-mapping: Use unsigned long for dma_attrs

2016-06-02 Thread Krzysztof Kozlowski
Split out subsystem specific changes for easier reviews. This will be
squashed with main commit.

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/video/fbdev/omap2/omapfb/omapfb-main.c | 12 ++--
 drivers/video/fbdev/omap2/omapfb/omapfb.h  |  3 +--
 2 files changed, 7 insertions(+), 8 deletions(-)

diff --git a/drivers/video/fbdev/omap2/omapfb/omapfb-main.c 
b/drivers/video/fbdev/omap2/omapfb/omapfb-main.c
index d3af01c94a58..59172a2185c0 100644
--- a/drivers/video/fbdev/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/fbdev/omap2/omapfb/omapfb-main.c
@@ -1332,7 +1332,7 @@ static void omapfb_free_fbmem(struct fb_info *fbi)
}
 
dma_free_attrs(fbdev->dev, rg->size, rg->token, rg->dma_handle,
-   >attrs);
+   rg->attrs);
 
rg->token = NULL;
rg->vaddr = NULL;
@@ -1370,7 +1370,7 @@ static int omapfb_alloc_fbmem(struct fb_info *fbi, 
unsigned long size,
struct omapfb2_device *fbdev = ofbi->fbdev;
struct omapfb2_mem_region *rg;
void *token;
-   DEFINE_DMA_ATTRS(attrs);
+   unsigned long attrs;
dma_addr_t dma_handle;
int r;
 
@@ -1386,15 +1386,15 @@ static int omapfb_alloc_fbmem(struct fb_info *fbi, 
unsigned long size,
 
size = PAGE_ALIGN(size);
 
-   dma_set_attr(DMA_ATTR_WRITE_COMBINE, );
+   attrs = DMA_ATTR_WRITE_COMBINE;
 
if (ofbi->rotation_type == OMAP_DSS_ROT_VRFB)
-   dma_set_attr(DMA_ATTR_NO_KERNEL_MAPPING, );
+   attrs |= DMA_ATTR_NO_KERNEL_MAPPING;
 
DBG("allocating %lu bytes for fb %d\n", size, ofbi->id);
 
token = dma_alloc_attrs(fbdev->dev, size, _handle,
-   GFP_KERNEL, );
+   GFP_KERNEL, attrs);
 
if (token == NULL) {
dev_err(fbdev->dev, "failed to allocate framebuffer\n");
@@ -1408,7 +1408,7 @@ static int omapfb_alloc_fbmem(struct fb_info *fbi, 
unsigned long size,
r = omap_vrfb_request_ctx(>vrfb);
if (r) {
dma_free_attrs(fbdev->dev, size, token, dma_handle,
-   );
+   attrs);
dev_err(fbdev->dev, "vrfb create ctx failed\n");
return r;
}
diff --git a/drivers/video/fbdev/omap2/omapfb/omapfb.h 
b/drivers/video/fbdev/omap2/omapfb/omapfb.h
index 623cd872a367..8aaa2f643820 100644
--- a/drivers/video/fbdev/omap2/omapfb/omapfb.h
+++ b/drivers/video/fbdev/omap2/omapfb/omapfb.h
@@ -28,7 +28,6 @@
 #endif
 
 #include 
-#include 
 #include 
 
 #include 
@@ -51,7 +50,7 @@ extern bool omapfb_debug;
 
 struct omapfb2_mem_region {
int id;
-   struct dma_attrs attrs;
+   unsigned long   attrs;
void*token;
dma_addr_t  dma_handle;
u32 paddr;
-- 
1.9.1


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


[Xen-devel] [RFC v3 20/45] xen: dma-mapping: Use unsigned long for dma_attrs

2016-06-02 Thread Krzysztof Kozlowski
Split out subsystem specific changes for easier reviews. This will be
squashed with main commit.

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/xen/swiotlb-xen.c | 14 +++---
 include/xen/swiotlb-xen.h | 12 ++--
 2 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 7399782c0998..87e6035c9e81 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -294,7 +294,7 @@ error:
 void *
 xen_swiotlb_alloc_coherent(struct device *hwdev, size_t size,
   dma_addr_t *dma_handle, gfp_t flags,
-  struct dma_attrs *attrs)
+  unsigned long attrs)
 {
void *ret;
int order = get_order(size);
@@ -346,7 +346,7 @@ EXPORT_SYMBOL_GPL(xen_swiotlb_alloc_coherent);
 
 void
 xen_swiotlb_free_coherent(struct device *hwdev, size_t size, void *vaddr,
- dma_addr_t dev_addr, struct dma_attrs *attrs)
+ dma_addr_t dev_addr, unsigned long attrs)
 {
int order = get_order(size);
phys_addr_t phys;
@@ -378,7 +378,7 @@ EXPORT_SYMBOL_GPL(xen_swiotlb_free_coherent);
 dma_addr_t xen_swiotlb_map_page(struct device *dev, struct page *page,
unsigned long offset, size_t size,
enum dma_data_direction dir,
-   struct dma_attrs *attrs)
+   unsigned long attrs)
 {
phys_addr_t map, phys = page_to_phys(page) + offset;
dma_addr_t dev_addr = xen_phys_to_bus(phys);
@@ -434,7 +434,7 @@ EXPORT_SYMBOL_GPL(xen_swiotlb_map_page);
  */
 static void xen_unmap_single(struct device *hwdev, dma_addr_t dev_addr,
 size_t size, enum dma_data_direction dir,
-struct dma_attrs *attrs)
+unsigned long attrs)
 {
phys_addr_t paddr = xen_bus_to_phys(dev_addr);
 
@@ -462,7 +462,7 @@ static void xen_unmap_single(struct device *hwdev, 
dma_addr_t dev_addr,
 
 void xen_swiotlb_unmap_page(struct device *hwdev, dma_addr_t dev_addr,
size_t size, enum dma_data_direction dir,
-   struct dma_attrs *attrs)
+   unsigned long attrs)
 {
xen_unmap_single(hwdev, dev_addr, size, dir, attrs);
 }
@@ -538,7 +538,7 @@ EXPORT_SYMBOL_GPL(xen_swiotlb_sync_single_for_device);
 int
 xen_swiotlb_map_sg_attrs(struct device *hwdev, struct scatterlist *sgl,
 int nelems, enum dma_data_direction dir,
-struct dma_attrs *attrs)
+unsigned long attrs)
 {
struct scatterlist *sg;
int i;
@@ -599,7 +599,7 @@ EXPORT_SYMBOL_GPL(xen_swiotlb_map_sg_attrs);
 void
 xen_swiotlb_unmap_sg_attrs(struct device *hwdev, struct scatterlist *sgl,
   int nelems, enum dma_data_direction dir,
-  struct dma_attrs *attrs)
+  unsigned long attrs)
 {
struct scatterlist *sg;
int i;
diff --git a/include/xen/swiotlb-xen.h b/include/xen/swiotlb-xen.h
index 8b2eb93ae8ba..7c35e279d1e3 100644
--- a/include/xen/swiotlb-xen.h
+++ b/include/xen/swiotlb-xen.h
@@ -9,30 +9,30 @@ extern int xen_swiotlb_init(int verbose, bool early);
 extern void
 *xen_swiotlb_alloc_coherent(struct device *hwdev, size_t size,
dma_addr_t *dma_handle, gfp_t flags,
-   struct dma_attrs *attrs);
+   unsigned long attrs);
 
 extern void
 xen_swiotlb_free_coherent(struct device *hwdev, size_t size,
  void *vaddr, dma_addr_t dma_handle,
- struct dma_attrs *attrs);
+ unsigned long attrs);
 
 extern dma_addr_t xen_swiotlb_map_page(struct device *dev, struct page *page,
   unsigned long offset, size_t size,
   enum dma_data_direction dir,
-  struct dma_attrs *attrs);
+  unsigned long attrs);
 
 extern void xen_swiotlb_unmap_page(struct device *hwdev, dma_addr_t dev_addr,
   size_t size, enum dma_data_direction dir,
-  struct dma_attrs *attrs);
+  unsigned long attrs);
 extern int
 xen_swiotlb_map_sg_attrs(struct device *hwdev, struct scatterlist *sgl,
 int nelems, enum dma_data_direction dir,
-struct dma_attrs *attrs);
+unsigned long attrs);
 
 extern void
 xen_swiotlb_unmap_sg_attrs(struct device *hwdev, struct scatterlist *sgl,
   int nelems, enum dma_data_direction dir,
-  struct dma_attrs *attrs);
+   

[Xen-devel] [RFC v3 21/45] swiotlb: dma-mapping: Use unsigned long for dma_attrs

2016-06-02 Thread Krzysztof Kozlowski
Split out subsystem specific changes for easier reviews. This will be
squashed with main commit.

Signed-off-by: Krzysztof Kozlowski 
---
 include/linux/swiotlb.h | 10 +-
 lib/swiotlb.c   | 13 +++--
 2 files changed, 12 insertions(+), 11 deletions(-)

diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 017fced60242..5f81f8a187f2 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -6,7 +6,6 @@
 #include 
 
 struct device;
-struct dma_attrs;
 struct page;
 struct scatterlist;
 
@@ -68,10 +67,10 @@ swiotlb_free_coherent(struct device *hwdev, size_t size,
 extern dma_addr_t swiotlb_map_page(struct device *dev, struct page *page,
   unsigned long offset, size_t size,
   enum dma_data_direction dir,
-  struct dma_attrs *attrs);
+  unsigned long attrs);
 extern void swiotlb_unmap_page(struct device *hwdev, dma_addr_t dev_addr,
   size_t size, enum dma_data_direction dir,
-  struct dma_attrs *attrs);
+  unsigned long attrs);
 
 extern int
 swiotlb_map_sg(struct device *hwdev, struct scatterlist *sg, int nents,
@@ -83,12 +82,13 @@ swiotlb_unmap_sg(struct device *hwdev, struct scatterlist 
*sg, int nents,
 
 extern int
 swiotlb_map_sg_attrs(struct device *hwdev, struct scatterlist *sgl, int nelems,
-enum dma_data_direction dir, struct dma_attrs *attrs);
+enum dma_data_direction dir,
+unsigned long attrs);
 
 extern void
 swiotlb_unmap_sg_attrs(struct device *hwdev, struct scatterlist *sgl,
   int nelems, enum dma_data_direction dir,
-  struct dma_attrs *attrs);
+  unsigned long attrs);
 
 extern void
 swiotlb_sync_single_for_cpu(struct device *hwdev, dma_addr_t dev_addr,
diff --git a/lib/swiotlb.c b/lib/swiotlb.c
index 76f29ecba8f4..22e13a0e19d7 100644
--- a/lib/swiotlb.c
+++ b/lib/swiotlb.c
@@ -738,7 +738,7 @@ swiotlb_full(struct device *dev, size_t size, enum 
dma_data_direction dir,
 dma_addr_t swiotlb_map_page(struct device *dev, struct page *page,
unsigned long offset, size_t size,
enum dma_data_direction dir,
-   struct dma_attrs *attrs)
+   unsigned long attrs)
 {
phys_addr_t map, phys = page_to_phys(page) + offset;
dma_addr_t dev_addr = phys_to_dma(dev, phys);
@@ -807,7 +807,7 @@ static void unmap_single(struct device *hwdev, dma_addr_t 
dev_addr,
 
 void swiotlb_unmap_page(struct device *hwdev, dma_addr_t dev_addr,
size_t size, enum dma_data_direction dir,
-   struct dma_attrs *attrs)
+   unsigned long attrs)
 {
unmap_single(hwdev, dev_addr, size, dir);
 }
@@ -877,7 +877,7 @@ EXPORT_SYMBOL(swiotlb_sync_single_for_device);
  */
 int
 swiotlb_map_sg_attrs(struct device *hwdev, struct scatterlist *sgl, int nelems,
-enum dma_data_direction dir, struct dma_attrs *attrs)
+enum dma_data_direction dir, unsigned long attrs)
 {
struct scatterlist *sg;
int i;
@@ -914,7 +914,7 @@ int
 swiotlb_map_sg(struct device *hwdev, struct scatterlist *sgl, int nelems,
   enum dma_data_direction dir)
 {
-   return swiotlb_map_sg_attrs(hwdev, sgl, nelems, dir, NULL);
+   return swiotlb_map_sg_attrs(hwdev, sgl, nelems, dir, 0);
 }
 EXPORT_SYMBOL(swiotlb_map_sg);
 
@@ -924,7 +924,8 @@ EXPORT_SYMBOL(swiotlb_map_sg);
  */
 void
 swiotlb_unmap_sg_attrs(struct device *hwdev, struct scatterlist *sgl,
-  int nelems, enum dma_data_direction dir, struct 
dma_attrs *attrs)
+  int nelems, enum dma_data_direction dir,
+  unsigned long attrs)
 {
struct scatterlist *sg;
int i;
@@ -941,7 +942,7 @@ void
 swiotlb_unmap_sg(struct device *hwdev, struct scatterlist *sgl, int nelems,
 enum dma_data_direction dir)
 {
-   return swiotlb_unmap_sg_attrs(hwdev, sgl, nelems, dir, NULL);
+   return swiotlb_unmap_sg_attrs(hwdev, sgl, nelems, dir, 0);
 }
 EXPORT_SYMBOL(swiotlb_unmap_sg);
 
-- 
1.9.1


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


[Xen-devel] [RFC v3 18/45] iommu: dma-mapping: Use unsigned long for dma_attrs

2016-06-02 Thread Krzysztof Kozlowski
Split out subsystem specific changes for easier reviews. This will be
squashed with main commit.

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/iommu/amd_iommu.c | 12 ++--
 drivers/iommu/dma-iommu.c |  6 +++---
 include/linux/dma-iommu.h |  6 +++---
 3 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 634f636393d5..afbb0de6a7f5 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -2716,7 +2716,7 @@ static void __unmap_single(struct dma_ops_domain *dma_dom,
 static dma_addr_t map_page(struct device *dev, struct page *page,
   unsigned long offset, size_t size,
   enum dma_data_direction dir,
-  struct dma_attrs *attrs)
+  unsigned long attrs)
 {
phys_addr_t paddr = page_to_phys(page) + offset;
struct protection_domain *domain;
@@ -2738,7 +2738,7 @@ static dma_addr_t map_page(struct device *dev, struct 
page *page,
  * The exported unmap_single function for dma_ops.
  */
 static void unmap_page(struct device *dev, dma_addr_t dma_addr, size_t size,
-  enum dma_data_direction dir, struct dma_attrs *attrs)
+  enum dma_data_direction dir, unsigned long attrs)
 {
struct protection_domain *domain;
 
@@ -2755,7 +2755,7 @@ static void unmap_page(struct device *dev, dma_addr_t 
dma_addr, size_t size,
  */
 static int map_sg(struct device *dev, struct scatterlist *sglist,
  int nelems, enum dma_data_direction dir,
- struct dma_attrs *attrs)
+ unsigned long attrs)
 {
struct protection_domain *domain;
int i;
@@ -2803,7 +2803,7 @@ unmap:
  */
 static void unmap_sg(struct device *dev, struct scatterlist *sglist,
 int nelems, enum dma_data_direction dir,
-struct dma_attrs *attrs)
+unsigned long attrs)
 {
struct protection_domain *domain;
struct scatterlist *s;
@@ -2825,7 +2825,7 @@ static void unmap_sg(struct device *dev, struct 
scatterlist *sglist,
  */
 static void *alloc_coherent(struct device *dev, size_t size,
dma_addr_t *dma_addr, gfp_t flag,
-   struct dma_attrs *attrs)
+   unsigned long attrs)
 {
u64 dma_mask = dev->coherent_dma_mask;
struct protection_domain *domain;
@@ -2879,7 +2879,7 @@ out_free:
  */
 static void free_coherent(struct device *dev, size_t size,
  void *virt_addr, dma_addr_t dma_addr,
- struct dma_attrs *attrs)
+ unsigned long attrs)
 {
struct protection_domain *domain;
struct page *page;
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index ea5a9ebf0f78..6c1bda504fb1 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -286,7 +286,7 @@ void iommu_dma_free(struct device *dev, struct page 
**pages, size_t size,
  *or NULL on failure.
  */
 struct page **iommu_dma_alloc(struct device *dev, size_t size, gfp_t gfp,
-   struct dma_attrs *attrs, int prot, dma_addr_t *handle,
+   unsigned long attrs, int prot, dma_addr_t *handle,
void (*flush_page)(struct device *, const void *, phys_addr_t))
 {
struct iommu_domain *domain = iommu_get_domain_for_dev(dev);
@@ -400,7 +400,7 @@ dma_addr_t iommu_dma_map_page(struct device *dev, struct 
page *page,
 }
 
 void iommu_dma_unmap_page(struct device *dev, dma_addr_t handle, size_t size,
-   enum dma_data_direction dir, struct dma_attrs *attrs)
+   enum dma_data_direction dir, unsigned long attrs)
 {
__iommu_dma_unmap(iommu_get_domain_for_dev(dev), handle);
 }
@@ -560,7 +560,7 @@ out_restore_sg:
 }
 
 void iommu_dma_unmap_sg(struct device *dev, struct scatterlist *sg, int nents,
-   enum dma_data_direction dir, struct dma_attrs *attrs)
+   enum dma_data_direction dir, unsigned long attrs)
 {
/*
 * The scatterlist segments are mapped into a single
diff --git a/include/linux/dma-iommu.h b/include/linux/dma-iommu.h
index 8443bbb5c071..81c5c8d167ad 100644
--- a/include/linux/dma-iommu.h
+++ b/include/linux/dma-iommu.h
@@ -39,7 +39,7 @@ int dma_direction_to_prot(enum dma_data_direction dir, bool 
coherent);
  * the arch code to take care of attributes and cache maintenance
  */
 struct page **iommu_dma_alloc(struct device *dev, size_t size, gfp_t gfp,
-   struct dma_attrs *attrs, int prot, dma_addr_t *handle,
+   unsigned long attrs, int prot, dma_addr_t *handle,
void (*flush_page)(struct device *, const void *, phys_addr_t));
 void iommu_dma_free(struct device *dev, struct page **pages, size_t size,
dma_addr_t *handle);
@@ -56,9 +56,9 @@ int 

[Xen-devel] [RFC v3 17/45] infiniband: dma-mapping: Use unsigned long for dma_attrs

2016-06-02 Thread Krzysztof Kozlowski
Split out subsystem specific changes for easier reviews. This will be
squashed with main commit.

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/infiniband/core/umem.c | 7 +++
 include/rdma/ib_verbs.h| 8 
 2 files changed, 7 insertions(+), 8 deletions(-)

diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
index fe4d2e1a8b58..75d8a8b178a5 100644
--- a/drivers/infiniband/core/umem.c
+++ b/drivers/infiniband/core/umem.c
@@ -37,7 +37,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
@@ -92,12 +91,12 @@ struct ib_umem *ib_umem_get(struct ib_ucontext *context, 
unsigned long addr,
unsigned long npages;
int ret;
int i;
-   DEFINE_DMA_ATTRS(attrs);
+   unsigned long attrs = 0;
struct scatterlist *sg, *sg_list_start;
int need_release = 0;
 
if (dmasync)
-   dma_set_attr(DMA_ATTR_WRITE_BARRIER, );
+   attrs |= DMA_ATTR_WRITE_BARRIER;
 
if (!size)
return ERR_PTR(-EINVAL);
@@ -215,7 +214,7 @@ struct ib_umem *ib_umem_get(struct ib_ucontext *context, 
unsigned long addr,
  umem->sg_head.sgl,
  umem->npages,
  DMA_BIDIRECTIONAL,
- );
+ attrs);
 
if (umem->nmap <= 0) {
ret = -ENOMEM;
diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
index 432bed510369..4d73928962c7 100644
--- a/include/rdma/ib_verbs.h
+++ b/include/rdma/ib_verbs.h
@@ -2819,7 +2819,7 @@ static inline void ib_dma_unmap_single(struct ib_device 
*dev,
 static inline u64 ib_dma_map_single_attrs(struct ib_device *dev,
  void *cpu_addr, size_t size,
  enum dma_data_direction direction,
- struct dma_attrs *attrs)
+ unsigned long attrs)
 {
return dma_map_single_attrs(dev->dma_device, cpu_addr, size,
direction, attrs);
@@ -2828,7 +2828,7 @@ static inline u64 ib_dma_map_single_attrs(struct 
ib_device *dev,
 static inline void ib_dma_unmap_single_attrs(struct ib_device *dev,
 u64 addr, size_t size,
 enum dma_data_direction direction,
-struct dma_attrs *attrs)
+unsigned long attrs)
 {
return dma_unmap_single_attrs(dev->dma_device, addr, size,
  direction, attrs);
@@ -2906,7 +2906,7 @@ static inline void ib_dma_unmap_sg(struct ib_device *dev,
 static inline int ib_dma_map_sg_attrs(struct ib_device *dev,
  struct scatterlist *sg, int nents,
  enum dma_data_direction direction,
- struct dma_attrs *attrs)
+ unsigned long attrs)
 {
return dma_map_sg_attrs(dev->dma_device, sg, nents, direction, attrs);
 }
@@ -2914,7 +2914,7 @@ static inline int ib_dma_map_sg_attrs(struct ib_device 
*dev,
 static inline void ib_dma_unmap_sg_attrs(struct ib_device *dev,
 struct scatterlist *sg, int nents,
 enum dma_data_direction direction,
-struct dma_attrs *attrs)
+unsigned long attrs)
 {
dma_unmap_sg_attrs(dev->dma_device, sg, nents, direction, attrs);
 }
-- 
1.9.1


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


[Xen-devel] [RFC v3 16/45] drm/rockship: dma-mapping: Use unsigned long for dma_attrs

2016-06-02 Thread Krzysztof Kozlowski
Split out subsystem specific changes for easier reviews. This will be
squashed with main commit.

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 17 +++--
 drivers/gpu/drm/rockchip/rockchip_drm_gem.h |  2 +-
 2 files changed, 8 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
index 9c2d8a894093..7b1788e2a808 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
@@ -17,8 +17,6 @@
 #include 
 #include 
 
-#include 
-
 #include "rockchip_drm_drv.h"
 #include "rockchip_drm_gem.h"
 
@@ -28,15 +26,14 @@ static int rockchip_gem_alloc_buf(struct 
rockchip_gem_object *rk_obj,
struct drm_gem_object *obj = _obj->base;
struct drm_device *drm = obj->dev;
 
-   init_dma_attrs(_obj->dma_attrs);
-   dma_set_attr(DMA_ATTR_WRITE_COMBINE, _obj->dma_attrs);
+   rk_obj->dma_attrs = DMA_ATTR_WRITE_COMBINE;
 
if (!alloc_kmap)
-   dma_set_attr(DMA_ATTR_NO_KERNEL_MAPPING, _obj->dma_attrs);
+   rk_obj->dma_attrs |= DMA_ATTR_NO_KERNEL_MAPPING;
 
rk_obj->kvaddr = dma_alloc_attrs(drm->dev, obj->size,
 _obj->dma_addr, GFP_KERNEL,
-_obj->dma_attrs);
+rk_obj->dma_attrs);
if (!rk_obj->kvaddr) {
DRM_ERROR("failed to allocate %#x byte dma buffer", obj->size);
return -ENOMEM;
@@ -51,7 +48,7 @@ static void rockchip_gem_free_buf(struct rockchip_gem_object 
*rk_obj)
struct drm_device *drm = obj->dev;
 
dma_free_attrs(drm->dev, obj->size, rk_obj->kvaddr, rk_obj->dma_addr,
-  _obj->dma_attrs);
+  rk_obj->dma_attrs);
 }
 
 static int rockchip_drm_gem_object_mmap(struct drm_gem_object *obj,
@@ -70,7 +67,7 @@ static int rockchip_drm_gem_object_mmap(struct drm_gem_object 
*obj,
vma->vm_pgoff = 0;
 
ret = dma_mmap_attrs(drm->dev, vma, rk_obj->kvaddr, rk_obj->dma_addr,
-obj->size, _obj->dma_attrs);
+obj->size, rk_obj->dma_attrs);
if (ret)
drm_gem_vm_close(vma);
 
@@ -262,7 +259,7 @@ struct sg_table *rockchip_gem_prime_get_sg_table(struct 
drm_gem_object *obj)
 
ret = dma_get_sgtable_attrs(drm->dev, sgt, rk_obj->kvaddr,
rk_obj->dma_addr, obj->size,
-   _obj->dma_attrs);
+   rk_obj->dma_attrs);
if (ret) {
DRM_ERROR("failed to allocate sgt, %d\n", ret);
kfree(sgt);
@@ -276,7 +273,7 @@ void *rockchip_gem_prime_vmap(struct drm_gem_object *obj)
 {
struct rockchip_gem_object *rk_obj = to_rockchip_obj(obj);
 
-   if (dma_get_attr(DMA_ATTR_NO_KERNEL_MAPPING, _obj->dma_attrs))
+   if (dma_get_attr(DMA_ATTR_NO_KERNEL_MAPPING, rk_obj->dma_attrs))
return NULL;
 
return rk_obj->kvaddr;
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_gem.h
index ad22618473a4..18b3488db4ec 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.h
@@ -23,7 +23,7 @@ struct rockchip_gem_object {
 
void *kvaddr;
dma_addr_t dma_addr;
-   struct dma_attrs dma_attrs;
+   unsigned long dma_attrs;
 };
 
 struct sg_table *rockchip_gem_prime_get_sg_table(struct drm_gem_object *obj);
-- 
1.9.1


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


[Xen-devel] [RFC v3 13/45] drm/mediatek: dma-mapping: Use unsigned long for dma_attrs

2016-06-02 Thread Krzysztof Kozlowski
Split out subsystem specific changes for easier reviews. This will be
squashed with main commit.

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/gpu/drm/mediatek/mtk_drm_gem.c | 13 ++---
 drivers/gpu/drm/mediatek/mtk_drm_gem.h |  2 +-
 2 files changed, 7 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_gem.c 
b/drivers/gpu/drm/mediatek/mtk_drm_gem.c
index fa2ec0cd00e8..7abc550ebc00 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_gem.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_gem.c
@@ -54,15 +54,14 @@ struct mtk_drm_gem_obj *mtk_drm_gem_create(struct 
drm_device *dev,
 
obj = _gem->base;
 
-   init_dma_attrs(_gem->dma_attrs);
-   dma_set_attr(DMA_ATTR_WRITE_COMBINE, _gem->dma_attrs);
+   mtk_gem->dma_attrs = DMA_ATTR_WRITE_COMBINE;
 
if (!alloc_kmap)
-   dma_set_attr(DMA_ATTR_NO_KERNEL_MAPPING, _gem->dma_attrs);
+   mtk_gem->dma_attrs |= DMA_ATTR_NO_KERNEL_MAPPING;
 
mtk_gem->cookie = dma_alloc_attrs(priv->dma_dev, obj->size,
  _gem->dma_addr, GFP_KERNEL,
- _gem->dma_attrs);
+ mtk_gem->dma_attrs);
if (!mtk_gem->cookie) {
DRM_ERROR("failed to allocate %zx byte dma buffer", obj->size);
ret = -ENOMEM;
@@ -93,7 +92,7 @@ void mtk_drm_gem_free_object(struct drm_gem_object *obj)
drm_prime_gem_destroy(obj, mtk_gem->sg);
else
dma_free_attrs(priv->dma_dev, obj->size, mtk_gem->cookie,
-  mtk_gem->dma_addr, _gem->dma_attrs);
+  mtk_gem->dma_addr, mtk_gem->dma_attrs);
 
/* release file pointer to gem object. */
drm_gem_object_release(obj);
@@ -173,7 +172,7 @@ static int mtk_drm_gem_object_mmap(struct drm_gem_object 
*obj,
vma->vm_pgoff = 0;
 
ret = dma_mmap_attrs(priv->dma_dev, vma, mtk_gem->cookie,
-mtk_gem->dma_addr, obj->size, _gem->dma_attrs);
+mtk_gem->dma_addr, obj->size, mtk_gem->dma_attrs);
if (ret)
drm_gem_vm_close(vma);
 
@@ -224,7 +223,7 @@ struct sg_table *mtk_gem_prime_get_sg_table(struct 
drm_gem_object *obj)
 
ret = dma_get_sgtable_attrs(priv->dma_dev, sgt, mtk_gem->cookie,
mtk_gem->dma_addr, obj->size,
-   _gem->dma_attrs);
+   mtk_gem->dma_attrs);
if (ret) {
DRM_ERROR("failed to allocate sgt, %d\n", ret);
kfree(sgt);
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_gem.h 
b/drivers/gpu/drm/mediatek/mtk_drm_gem.h
index 3a2a5624a1cb..2752718fa5b2 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_gem.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_gem.h
@@ -35,7 +35,7 @@ struct mtk_drm_gem_obj {
void*cookie;
void*kvaddr;
dma_addr_t  dma_addr;
-   struct dma_attrsdma_attrs;
+   unsigned long   dma_attrs;
struct sg_table *sg;
 };
 
-- 
1.9.1


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


[Xen-devel] [RFC v3 12/45] drm/exynos: dma-mapping: Use unsigned long for dma_attrs

2016-06-02 Thread Krzysztof Kozlowski
Split out subsystem specific changes for easier reviews. This will be
squashed with main commit.

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |  2 +-
 drivers/gpu/drm/exynos/exynos_drm_g2d.c   | 12 +---
 drivers/gpu/drm/exynos/exynos_drm_gem.c   | 20 ++--
 drivers/gpu/drm/exynos/exynos_drm_gem.h   |  2 +-
 4 files changed, 17 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index 67dcd6831291..dd091175fc2d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -52,7 +52,7 @@ static int exynos_drm_fb_mmap(struct fb_info *info,
 
ret = dma_mmap_attrs(to_dma_dev(helper->dev), vma, exynos_gem->cookie,
 exynos_gem->dma_addr, exynos_gem->size,
-_gem->dma_attrs);
+exynos_gem->dma_attrs);
if (ret < 0) {
DRM_ERROR("failed to mmap.\n");
return ret;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c 
b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index 493552368295..15539aea8415 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -17,7 +17,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include 
@@ -235,7 +234,7 @@ struct g2d_data {
struct mutexcmdlist_mutex;
dma_addr_t  cmdlist_pool;
void*cmdlist_pool_virt;
-   struct dma_attrscmdlist_dma_attrs;
+   unsigned long   cmdlist_dma_attrs;
 
/* runqueue*/
struct g2d_runqueue_node*runqueue_node;
@@ -256,13 +255,12 @@ static int g2d_init_cmdlist(struct g2d_data *g2d)
int ret;
struct g2d_buf_info *buf_info;
 
-   init_dma_attrs(>cmdlist_dma_attrs);
-   dma_set_attr(DMA_ATTR_WRITE_COMBINE, >cmdlist_dma_attrs);
+   g2d->cmdlist_dma_attrs = DMA_ATTR_WRITE_COMBINE;
 
g2d->cmdlist_pool_virt = dma_alloc_attrs(to_dma_dev(subdrv->drm_dev),
G2D_CMDLIST_POOL_SIZE,
>cmdlist_pool, GFP_KERNEL,
-   >cmdlist_dma_attrs);
+   g2d->cmdlist_dma_attrs);
if (!g2d->cmdlist_pool_virt) {
dev_err(dev, "failed to allocate dma memory\n");
return -ENOMEM;
@@ -295,7 +293,7 @@ static int g2d_init_cmdlist(struct g2d_data *g2d)
 err:
dma_free_attrs(to_dma_dev(subdrv->drm_dev), G2D_CMDLIST_POOL_SIZE,
g2d->cmdlist_pool_virt,
-   g2d->cmdlist_pool, >cmdlist_dma_attrs);
+   g2d->cmdlist_pool, g2d->cmdlist_dma_attrs);
return ret;
 }
 
@@ -309,7 +307,7 @@ static void g2d_fini_cmdlist(struct g2d_data *g2d)
dma_free_attrs(to_dma_dev(subdrv->drm_dev),
G2D_CMDLIST_POOL_SIZE,
g2d->cmdlist_pool_virt,
-   g2d->cmdlist_pool, >cmdlist_dma_attrs);
+   g2d->cmdlist_pool, g2d->cmdlist_dma_attrs);
}
 }
 
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index cdf9f1af4347..f2ae72ba7d5a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -24,7 +24,7 @@
 static int exynos_drm_alloc_buf(struct exynos_drm_gem *exynos_gem)
 {
struct drm_device *dev = exynos_gem->base.dev;
-   enum dma_attr attr;
+   unsigned long attr;
unsigned int nr_pages;
struct sg_table sgt;
int ret = -ENOMEM;
@@ -34,7 +34,7 @@ static int exynos_drm_alloc_buf(struct exynos_drm_gem 
*exynos_gem)
return 0;
}
 
-   init_dma_attrs(_gem->dma_attrs);
+   exynos_gem->dma_attrs = 0;
 
/*
 * if EXYNOS_BO_CONTIG, fully physically contiguous memory
@@ -42,7 +42,7 @@ static int exynos_drm_alloc_buf(struct exynos_drm_gem 
*exynos_gem)
 * as possible.
 */
if (!(exynos_gem->flags & EXYNOS_BO_NONCONTIG))
-   dma_set_attr(DMA_ATTR_FORCE_CONTIGUOUS, _gem->dma_attrs);
+   exynos_gem->dma_attrs |= DMA_ATTR_FORCE_CONTIGUOUS;
 
/*
 * if EXYNOS_BO_WC or EXYNOS_BO_NONCACHABLE, writecombine mapping
@@ -54,8 +54,8 @@ static int exynos_drm_alloc_buf(struct exynos_drm_gem 
*exynos_gem)
else
attr = DMA_ATTR_NON_CONSISTENT;
 
-   dma_set_attr(attr, _gem->dma_attrs);
-   dma_set_attr(DMA_ATTR_NO_KERNEL_MAPPING, _gem->dma_attrs);
+   exynos_gem->dma_attrs |= attr;
+   exynos_gem->dma_attrs |= DMA_ATTR_NO_KERNEL_MAPPING;
 
nr_pages = exynos_gem->size >> 

[Xen-devel] [RFC v3 11/45] frv: dma-mapping: Use unsigned long for dma_attrs

2016-06-02 Thread Krzysztof Kozlowski
Split out subsystem specific changes for easier reviews. This will be
squashed with main commit.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/frv/mb93090-mb00/pci-dma-nommu.c | 8 
 arch/frv/mb93090-mb00/pci-dma.c   | 9 -
 2 files changed, 8 insertions(+), 9 deletions(-)

diff --git a/arch/frv/mb93090-mb00/pci-dma-nommu.c 
b/arch/frv/mb93090-mb00/pci-dma-nommu.c
index 082be49b5df0..90f2e4cb33d6 100644
--- a/arch/frv/mb93090-mb00/pci-dma-nommu.c
+++ b/arch/frv/mb93090-mb00/pci-dma-nommu.c
@@ -35,7 +35,7 @@ static DEFINE_SPINLOCK(dma_alloc_lock);
 static LIST_HEAD(dma_alloc_list);
 
 static void *frv_dma_alloc(struct device *hwdev, size_t size, dma_addr_t 
*dma_handle,
-   gfp_t gfp, struct dma_attrs *attrs)
+   gfp_t gfp, unsigned long attrs)
 {
struct dma_alloc_record *new;
struct list_head *this = _alloc_list;
@@ -86,7 +86,7 @@ static void *frv_dma_alloc(struct device *hwdev, size_t size, 
dma_addr_t *dma_ha
 }
 
 static void frv_dma_free(struct device *hwdev, size_t size, void *vaddr,
-   dma_addr_t dma_handle, struct dma_attrs *attrs)
+   dma_addr_t dma_handle, unsigned long attrs)
 {
struct dma_alloc_record *rec;
unsigned long flags;
@@ -107,7 +107,7 @@ static void frv_dma_free(struct device *hwdev, size_t size, 
void *vaddr,
 
 static int frv_dma_map_sg(struct device *dev, struct scatterlist *sglist,
int nents, enum dma_data_direction direction,
-   struct dma_attrs *attrs)
+   unsigned long attrs)
 {
int i;
struct scatterlist *sg;
@@ -124,7 +124,7 @@ static int frv_dma_map_sg(struct device *dev, struct 
scatterlist *sglist,
 
 static dma_addr_t frv_dma_map_page(struct device *dev, struct page *page,
unsigned long offset, size_t size,
-   enum dma_data_direction direction, struct dma_attrs *attrs)
+   enum dma_data_direction direction, unsigned long attrs)
 {
BUG_ON(direction == DMA_NONE);
flush_dcache_page(page);
diff --git a/arch/frv/mb93090-mb00/pci-dma.c b/arch/frv/mb93090-mb00/pci-dma.c
index 316b7b65348d..f585745b1abc 100644
--- a/arch/frv/mb93090-mb00/pci-dma.c
+++ b/arch/frv/mb93090-mb00/pci-dma.c
@@ -19,8 +19,7 @@
 #include 
 
 static void *frv_dma_alloc(struct device *hwdev, size_t size,
-   dma_addr_t *dma_handle, gfp_t gfp,
-   struct dma_attrs *attrs)
+   dma_addr_t *dma_handle, gfp_t gfp, unsigned long attrs)
 {
void *ret;
 
@@ -32,14 +31,14 @@ static void *frv_dma_alloc(struct device *hwdev, size_t 
size,
 }
 
 static void frv_dma_free(struct device *hwdev, size_t size, void *vaddr,
-   dma_addr_t dma_handle, struct dma_attrs *attrs)
+   dma_addr_t dma_handle, unsigned long attrs)
 {
consistent_free(vaddr);
 }
 
 static int frv_dma_map_sg(struct device *dev, struct scatterlist *sglist,
int nents, enum dma_data_direction direction,
-   struct dma_attrs *attrs)
+   unsigned long attrs)
 {
unsigned long dampr2;
void *vaddr;
@@ -69,7 +68,7 @@ static int frv_dma_map_sg(struct device *dev, struct 
scatterlist *sglist,
 
 static dma_addr_t frv_dma_map_page(struct device *dev, struct page *page,
unsigned long offset, size_t size,
-   enum dma_data_direction direction, struct dma_attrs *attrs)
+   enum dma_data_direction direction, unsigned long attrs)
 {
flush_dcache_page(page);
return (dma_addr_t) page_to_phys(page) + offset;
-- 
1.9.1


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


[Xen-devel] [RFC v3 07/45] avr32: dma-mapping: Use unsigned long for dma_attrs

2016-06-02 Thread Krzysztof Kozlowski
Split out subsystem specific changes for easier reviews. This will be
squashed with main commit.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/avr32/mm/dma-coherent.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/avr32/mm/dma-coherent.c b/arch/avr32/mm/dma-coherent.c
index 92cf1fb2b3e6..fc51f4421933 100644
--- a/arch/avr32/mm/dma-coherent.c
+++ b/arch/avr32/mm/dma-coherent.c
@@ -99,7 +99,7 @@ static void __dma_free(struct device *dev, size_t size,
 }
 
 static void *avr32_dma_alloc(struct device *dev, size_t size,
-   dma_addr_t *handle, gfp_t gfp, struct dma_attrs *attrs)
+   dma_addr_t *handle, gfp_t gfp, unsigned long attrs)
 {
struct page *page;
dma_addr_t phys;
@@ -119,7 +119,7 @@ static void *avr32_dma_alloc(struct device *dev, size_t 
size,
 }
 
 static void avr32_dma_free(struct device *dev, size_t size,
-   void *cpu_addr, dma_addr_t handle, struct dma_attrs *attrs)
+   void *cpu_addr, dma_addr_t handle, unsigned long attrs)
 {
struct page *page;
 
@@ -142,7 +142,7 @@ static void avr32_dma_free(struct device *dev, size_t size,
 
 static dma_addr_t avr32_dma_map_page(struct device *dev, struct page *page,
unsigned long offset, size_t size,
-   enum dma_data_direction direction, struct dma_attrs *attrs)
+   enum dma_data_direction direction, unsigned long attrs)
 {
void *cpu_addr = page_address(page) + offset;
 
@@ -152,7 +152,7 @@ static dma_addr_t avr32_dma_map_page(struct device *dev, 
struct page *page,
 
 static int avr32_dma_map_sg(struct device *dev, struct scatterlist *sglist,
int nents, enum dma_data_direction direction,
-   struct dma_attrs *attrs)
+   unsigned long attrs)
 {
int i;
struct scatterlist *sg;
-- 
1.9.1


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


[Xen-devel] [RFC v3 02/45] dma-mapping: Use unsigned long for dma_attrs

2016-06-02 Thread Krzysztof Kozlowski
The dma-mapping core and the implementations do not change the
DMA attributes passed by pointer.  Thus the pointer can point to const
data.  However the attributes do not have to be a bitfield. Instead
unsigned long will do fine:

1. This is just simpler.  Both in terms of reading the code and setting
   attributes.  Instead of initializing local attributes on the stack
   and passing pointer to it to dma_set_attr(), just set the bits.

2. It brings safeness and checking for const correctness because the
   attributes are passed by value.

Semantic patches for this change (at least most of them):
===
virtual patch
virtual context

@r@
identifier f, attrs;

@@
f(...,
- struct dma_attrs *attrs
+ unsigned long attrs
, ...)
{
...
}

@@
identifier r.f;
@@
f(...,
- NULL
+ 0
 )
===
// Options: --all-includes
virtual patch
virtual context

@r@
identifier f, attrs;
type t;

@@
t f(..., struct dma_attrs *attrs);

@@
identifier r.f;
@@
f(...,
- NULL
+ 0
 )
===

Signed-off-by: Krzysztof Kozlowski 
---
 Documentation/DMA-API.txt|  29 +--
 Documentation/DMA-attributes.txt |   2 +-
 include/linux/dma-attrs.h|  71 -
 include/linux/dma-mapping.h  | 108 +++
 lib/dma-noop.c   |   9 ++--
 5 files changed, 83 insertions(+), 136 deletions(-)
 delete mode 100644 include/linux/dma-attrs.h

diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt
index 45ef3f279c3b..24f9688bb98a 100644
--- a/Documentation/DMA-API.txt
+++ b/Documentation/DMA-API.txt
@@ -369,35 +369,32 @@ See also dma_map_single().
 dma_addr_t
 dma_map_single_attrs(struct device *dev, void *cpu_addr, size_t size,
 enum dma_data_direction dir,
-struct dma_attrs *attrs)
+unsigned long attrs)
 
 void
 dma_unmap_single_attrs(struct device *dev, dma_addr_t dma_addr,
   size_t size, enum dma_data_direction dir,
-  struct dma_attrs *attrs)
+  unsigned long attrs)
 
 int
 dma_map_sg_attrs(struct device *dev, struct scatterlist *sgl,
 int nents, enum dma_data_direction dir,
-struct dma_attrs *attrs)
+unsigned long attrs)
 
 void
 dma_unmap_sg_attrs(struct device *dev, struct scatterlist *sgl,
   int nents, enum dma_data_direction dir,
-  struct dma_attrs *attrs)
+  unsigned long attrs)
 
 The four functions above are just like the counterpart functions
 without the _attrs suffixes, except that they pass an optional
-struct dma_attrs*.
-
-struct dma_attrs encapsulates a set of "DMA attributes". For the
-definition of struct dma_attrs see linux/dma-attrs.h.
+dma_attrs.
 
 The interpretation of DMA attributes is architecture-specific, and
 each attribute should be documented in Documentation/DMA-attributes.txt.
 
-If struct dma_attrs* is NULL, the semantics of each of these
-functions is identical to those of the corresponding function
+If dma_attrs are 0, the semantics of each of these functions
+is identical to those of the corresponding function
 without the _attrs suffix. As a result dma_map_single_attrs()
 can generally replace dma_map_single(), etc.
 
@@ -405,15 +402,15 @@ As an example of the use of the *_attrs functions, here's 
how
 you could pass an attribute DMA_ATTR_FOO when mapping memory
 for DMA:
 
-#include 
-/* DMA_ATTR_FOO should be defined in linux/dma-attrs.h and
+#include 
+/* DMA_ATTR_FOO should be defined in linux/dma-mapping.h and
  * documented in Documentation/DMA-attributes.txt */
 ...
 
-   DEFINE_DMA_ATTRS(attrs);
-   dma_set_attr(DMA_ATTR_FOO, );
+   unsigned long attr;
+   attr |= DMA_ATTR_FOO;

-   n = dma_map_sg_attrs(dev, sg, nents, DMA_TO_DEVICE, );
+   n = dma_map_sg_attrs(dev, sg, nents, DMA_TO_DEVICE, attr);

 
 Architectures that care about DMA_ATTR_FOO would check for its
@@ -422,7 +419,7 @@ routines, e.g.:
 
 void whizco_dma_map_sg_attrs(struct device *dev, dma_addr_t dma_addr,
 size_t size, enum dma_data_direction dir,
-struct dma_attrs *attrs)
+unsigned long attrs)
 {

int foo =  dma_get_attr(DMA_ATTR_FOO, attrs);
diff --git a/Documentation/DMA-attributes.txt b/Documentation/DMA-attributes.txt
index e8cf9cf873b3..2d455a5cf671 100644
--- a/Documentation/DMA-attributes.txt
+++ b/Documentation/DMA-attributes.txt
@@ -2,7 +2,7 @@
==
 
 This document describes the semantics of the DMA attributes that are
-defined in linux/dma-attrs.h.
+defined in linux/dma-mapping.h.
 
 DMA_ATTR_WRITE_BARRIER
 --
diff --git a/include/linux/dma-attrs.h b/include/linux/dma-attrs.h
deleted file mode 100644
index 5246239a4953..
--- a/include/linux/dma-attrs.h
+++ /dev/null
@@ -1,71 +0,0 @@

[Xen-devel] [RFC v3 01/45] powerpc: dma-mapping: Don't hard-code the value of DMA_ATTR_WEAK_ORDERING

2016-06-02 Thread Krzysztof Kozlowski
Hard-coded value of DMA_ATTR_WEAK_ORDERING is then compared with the
symbol.  This will stop matching if the value of symbol is changed (when
switching DMA attributes to unsigned long).

Signed-off-by: Krzysztof Kozlowski 
---
 arch/powerpc/platforms/cell/iommu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/platforms/cell/iommu.c 
b/arch/powerpc/platforms/cell/iommu.c
index 14a582b21274..0c2794d2b6c0 100644
--- a/arch/powerpc/platforms/cell/iommu.c
+++ b/arch/powerpc/platforms/cell/iommu.c
@@ -1162,7 +1162,7 @@ static int __init setup_iommu_fixed(char *str)
pciep = of_find_node_by_type(NULL, "pcie-endpoint");
 
if (strcmp(str, "weak") == 0 || (pciep && strcmp(str, "strong") != 0))
-   iommu_fixed_is_weak = 1;
+   iommu_fixed_is_weak = DMA_ATTR_WEAK_ORDERING;
 
of_node_put(pciep);
 
-- 
1.9.1


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


[Xen-devel] [RFC v3 00/45] dma-mapping: Use unsigned long for dma_attrs

2016-06-02 Thread Krzysztof Kozlowski
Hi,


This is third approach (complete this time) for replacing struct
dma_attrs with unsigned long.

The main patch (2/45) doing the change is split into many subpatches
for easier review (3-43).  They should be squashed together when
applying.


*Important:* Patchset is *only* build tested on allyesconfigs: ARM,
ARM64, i386, x86_64 and powerpc. Please provide reviewes and tests
for other platforms.

Rebased on next-20160602.

For easier testing the patchset is available here:
repo:   https://github.com/krzk/linux
branch: for-next/dma-attrs-const-v3


I didn't CC all the maintainers... the list is too big.

Changes since v2

1. Follow Christoph Hellwig's comments (don't use BIT add
   documentation, remove dma_get_attr).


Rationale
=
The dma-mapping core and the implementations do not change the
DMA attributes passed by pointer.  Thus the pointer can point to const
data.  However the attributes do not have to be a bitfield. Instead
unsigned long will do fine:

1. This is just simpler.  Both in terms of reading the code and setting
   attributes.  Instead of initializing local attributes on the stack
   and passing pointer to it to dma_set_attr(), just set the bits.

2. It brings safeness and checking for const correctness because the
   attributes are passed by value.


Best regards,
Krzysztof


Krzysztof Kozlowski (45):
  powerpc: dma-mapping: Don't hard-code the value of
DMA_ATTR_WEAK_ORDERING
  dma-mapping: Use unsigned long for dma_attrs
  alpha: dma-mapping: Use unsigned long for dma_attrs
  arc: dma-mapping: Use unsigned long for dma_attrs
  ARM: dma-mapping: Use unsigned long for dma_attrs
  arm64: dma-mapping: Use unsigned long for dma_attrs
  avr32: dma-mapping: Use unsigned long for dma_attrs
  blackfin: dma-mapping: Use unsigned long for dma_attrs
  c6x: dma-mapping: Use unsigned long for dma_attrs
  cris: dma-mapping: Use unsigned long for dma_attrs
  frv: dma-mapping: Use unsigned long for dma_attrs
  drm/exynos: dma-mapping: Use unsigned long for dma_attrs
  drm/mediatek: dma-mapping: Use unsigned long for dma_attrs
  drm/msm: dma-mapping: Use unsigned long for dma_attrs
  drm/nouveau: dma-mapping: Use unsigned long for dma_attrs
  drm/rockship: dma-mapping: Use unsigned long for dma_attrs
  infiniband: dma-mapping: Use unsigned long for dma_attrs
  iommu: dma-mapping: Use unsigned long for dma_attrs
  [media] dma-mapping: Use unsigned long for dma_attrs
  xen: dma-mapping: Use unsigned long for dma_attrs
  swiotlb: dma-mapping: Use unsigned long for dma_attrs
  powerpc: dma-mapping: Use unsigned long for dma_attrs
  video: dma-mapping: Use unsigned long for dma_attrs
  x86: dma-mapping: Use unsigned long for dma_attrs
  iommu: intel: dma-mapping: Use unsigned long for dma_attrs
  h8300: dma-mapping: Use unsigned long for dma_attrs
  hexagon: dma-mapping: Use unsigned long for dma_attrs
  ia64: dma-mapping: Use unsigned long for dma_attrs
  m68k: dma-mapping: Use unsigned long for dma_attrs
  metag: dma-mapping: Use unsigned long for dma_attrs
  microblaze: dma-mapping: Use unsigned long for dma_attrs
  mips: dma-mapping: Use unsigned long for dma_attrs
  mn10300: dma-mapping: Use unsigned long for dma_attrs
  nios2: dma-mapping: Use unsigned long for dma_attrs
  openrisc: dma-mapping: Use unsigned long for dma_attrs
  parisc: dma-mapping: Use unsigned long for dma_attrs
  misc: mic: dma-mapping: Use unsigned long for dma_attrs
  s390: dma-mapping: Use unsigned long for dma_attrs
  sh: dma-mapping: Use unsigned long for dma_attrs
  sparc: dma-mapping: Use unsigned long for dma_attrs
  tile: dma-mapping: Use unsigned long for dma_attrs
  unicore32: dma-mapping: Use unsigned long for dma_attrs
  xtensa: dma-mapping: Use unsigned long for dma_attrs
  dma-mapping: Remove dma_get_attr
  dma-mapping: Document the DMA attributes right in declaration

 Documentation/DMA-API.txt  |  33 +++---
 Documentation/DMA-attributes.txt   |   2 +-
 arch/alpha/include/asm/dma-mapping.h   |   2 -
 arch/alpha/kernel/pci-noop.c   |   2 +-
 arch/alpha/kernel/pci_iommu.c  |  12 +-
 arch/arc/mm/dma.c  |  12 +-
 arch/arm/common/dmabounce.c|   4 +-
 arch/arm/include/asm/dma-mapping.h |  13 +--
 arch/arm/include/asm/xen/page-coherent.h   |  16 +--
 arch/arm/mm/dma-mapping.c  | 117 +--
 arch/arm/xen/mm.c  |   8 +-
 arch/arm64/mm/dma-mapping.c|  67 +--
 arch/avr32/mm/dma-coherent.c   |  12 +-
 arch/blackfin/kernel/dma-mapping.c |   8 +-
 arch/c6x/include/asm/dma-mapping.h |   4 +-
 arch/c6x/kernel/dma.c  |   9 +-
 arch/c6x/mm/dma-coherent.c |   4 +-
 arch/cris/arch-v32/drivers/pci/dma.c   |   9 +-
 arch/frv

[Xen-devel] [RFC v3 06/45] arm64: dma-mapping: Use unsigned long for dma_attrs

2016-06-02 Thread Krzysztof Kozlowski
Split out subsystem specific changes for easier reviews. This will be
squashed with main commit.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/arm64/mm/dma-mapping.c | 57 +++--
 1 file changed, 29 insertions(+), 28 deletions(-)

diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index c566ec83719f..a7686028dfeb 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -29,7 +29,7 @@
 
 #include 
 
-static pgprot_t __get_dma_pgprot(struct dma_attrs *attrs, pgprot_t prot,
+static pgprot_t __get_dma_pgprot(unsigned long attrs, pgprot_t prot,
 bool coherent)
 {
if (!coherent || dma_get_attr(DMA_ATTR_WRITE_COMBINE, attrs))
@@ -88,7 +88,7 @@ static int __free_from_pool(void *start, size_t size)
 
 static void *__dma_alloc_coherent(struct device *dev, size_t size,
  dma_addr_t *dma_handle, gfp_t flags,
- struct dma_attrs *attrs)
+ unsigned long attrs)
 {
if (dev == NULL) {
WARN_ONCE(1, "Use an actual device structure for DMA 
allocation\n");
@@ -118,7 +118,7 @@ static void *__dma_alloc_coherent(struct device *dev, 
size_t size,
 
 static void __dma_free_coherent(struct device *dev, size_t size,
void *vaddr, dma_addr_t dma_handle,
-   struct dma_attrs *attrs)
+   unsigned long attrs)
 {
bool freed;
phys_addr_t paddr = dma_to_phys(dev, dma_handle);
@@ -137,7 +137,7 @@ static void __dma_free_coherent(struct device *dev, size_t 
size,
 
 static void *__dma_alloc(struct device *dev, size_t size,
 dma_addr_t *dma_handle, gfp_t flags,
-struct dma_attrs *attrs)
+unsigned long attrs)
 {
struct page *page;
void *ptr, *coherent_ptr;
@@ -185,7 +185,7 @@ no_mem:
 
 static void __dma_free(struct device *dev, size_t size,
   void *vaddr, dma_addr_t dma_handle,
-  struct dma_attrs *attrs)
+  unsigned long attrs)
 {
void *swiotlb_addr = phys_to_virt(dma_to_phys(dev, dma_handle));
 
@@ -202,7 +202,7 @@ static void __dma_free(struct device *dev, size_t size,
 static dma_addr_t __swiotlb_map_page(struct device *dev, struct page *page,
 unsigned long offset, size_t size,
 enum dma_data_direction dir,
-struct dma_attrs *attrs)
+unsigned long attrs)
 {
dma_addr_t dev_addr;
 
@@ -216,7 +216,7 @@ static dma_addr_t __swiotlb_map_page(struct device *dev, 
struct page *page,
 
 static void __swiotlb_unmap_page(struct device *dev, dma_addr_t dev_addr,
 size_t size, enum dma_data_direction dir,
-struct dma_attrs *attrs)
+unsigned long attrs)
 {
if (!is_device_dma_coherent(dev))
__dma_unmap_area(phys_to_virt(dma_to_phys(dev, dev_addr)), 
size, dir);
@@ -225,7 +225,7 @@ static void __swiotlb_unmap_page(struct device *dev, 
dma_addr_t dev_addr,
 
 static int __swiotlb_map_sg_attrs(struct device *dev, struct scatterlist *sgl,
  int nelems, enum dma_data_direction dir,
- struct dma_attrs *attrs)
+ unsigned long attrs)
 {
struct scatterlist *sg;
int i, ret;
@@ -242,7 +242,7 @@ static int __swiotlb_map_sg_attrs(struct device *dev, 
struct scatterlist *sgl,
 static void __swiotlb_unmap_sg_attrs(struct device *dev,
 struct scatterlist *sgl, int nelems,
 enum dma_data_direction dir,
-struct dma_attrs *attrs)
+unsigned long attrs)
 {
struct scatterlist *sg;
int i;
@@ -303,7 +303,7 @@ static void __swiotlb_sync_sg_for_device(struct device *dev,
 static int __swiotlb_mmap(struct device *dev,
  struct vm_area_struct *vma,
  void *cpu_addr, dma_addr_t dma_addr, size_t size,
- struct dma_attrs *attrs)
+ unsigned long attrs)
 {
int ret = -ENXIO;
unsigned long nr_vma_pages = (vma->vm_end - vma->vm_start) >>
@@ -330,7 +330,7 @@ static int __swiotlb_mmap(struct device *dev,
 
 static int __swiotlb_get_sgtable(struct device *dev, struct sg_table *sgt,
 void *cpu_addr, dma_addr_t handle, size_t size,
-struct dma_attrs *attrs)
+unsigned long attrs)
 {
int ret = sg_alloc_table(sgt, 1, GFP_KERNEL);
 
@@ 

[Xen-devel] [RFC v3 03/45] alpha: dma-mapping: Use unsigned long for dma_attrs

2016-06-02 Thread Krzysztof Kozlowski
Split out subsystem specific changes for easier reviews. This will be
squashed with main commit.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/alpha/include/asm/dma-mapping.h |  2 --
 arch/alpha/kernel/pci-noop.c |  2 +-
 arch/alpha/kernel/pci_iommu.c| 12 ++--
 3 files changed, 7 insertions(+), 9 deletions(-)

diff --git a/arch/alpha/include/asm/dma-mapping.h 
b/arch/alpha/include/asm/dma-mapping.h
index 3c3451f58ff4..c63b6ac19ee5 100644
--- a/arch/alpha/include/asm/dma-mapping.h
+++ b/arch/alpha/include/asm/dma-mapping.h
@@ -1,8 +1,6 @@
 #ifndef _ALPHA_DMA_MAPPING_H
 #define _ALPHA_DMA_MAPPING_H
 
-#include 
-
 extern struct dma_map_ops *dma_ops;
 
 static inline struct dma_map_ops *get_dma_ops(struct device *dev)
diff --git a/arch/alpha/kernel/pci-noop.c b/arch/alpha/kernel/pci-noop.c
index 8e735b5e56bd..bb152e21e5ae 100644
--- a/arch/alpha/kernel/pci-noop.c
+++ b/arch/alpha/kernel/pci-noop.c
@@ -109,7 +109,7 @@ sys_pciconfig_write(unsigned long bus, unsigned long dfn,
 
 static void *alpha_noop_alloc_coherent(struct device *dev, size_t size,
   dma_addr_t *dma_handle, gfp_t gfp,
-  struct dma_attrs *attrs)
+  unsigned long attrs)
 {
void *ret;
 
diff --git a/arch/alpha/kernel/pci_iommu.c b/arch/alpha/kernel/pci_iommu.c
index 8969bf2dfe3a..451fc9cdd323 100644
--- a/arch/alpha/kernel/pci_iommu.c
+++ b/arch/alpha/kernel/pci_iommu.c
@@ -349,7 +349,7 @@ static struct pci_dev *alpha_gendev_to_pci(struct device 
*dev)
 static dma_addr_t alpha_pci_map_page(struct device *dev, struct page *page,
 unsigned long offset, size_t size,
 enum dma_data_direction dir,
-struct dma_attrs *attrs)
+unsigned long attrs)
 {
struct pci_dev *pdev = alpha_gendev_to_pci(dev);
int dac_allowed;
@@ -369,7 +369,7 @@ static dma_addr_t alpha_pci_map_page(struct device *dev, 
struct page *page,
 
 static void alpha_pci_unmap_page(struct device *dev, dma_addr_t dma_addr,
 size_t size, enum dma_data_direction dir,
-struct dma_attrs *attrs)
+unsigned long attrs)
 {
unsigned long flags;
struct pci_dev *pdev = alpha_gendev_to_pci(dev);
@@ -433,7 +433,7 @@ static void alpha_pci_unmap_page(struct device *dev, 
dma_addr_t dma_addr,
 
 static void *alpha_pci_alloc_coherent(struct device *dev, size_t size,
  dma_addr_t *dma_addrp, gfp_t gfp,
- struct dma_attrs *attrs)
+ unsigned long attrs)
 {
struct pci_dev *pdev = alpha_gendev_to_pci(dev);
void *cpu_addr;
@@ -478,7 +478,7 @@ try_again:
 
 static void alpha_pci_free_coherent(struct device *dev, size_t size,
void *cpu_addr, dma_addr_t dma_addr,
-   struct dma_attrs *attrs)
+   unsigned long attrs)
 {
struct pci_dev *pdev = alpha_gendev_to_pci(dev);
pci_unmap_single(pdev, dma_addr, size, PCI_DMA_BIDIRECTIONAL);
@@ -651,7 +651,7 @@ sg_fill(struct device *dev, struct scatterlist *leader, 
struct scatterlist *end,
 
 static int alpha_pci_map_sg(struct device *dev, struct scatterlist *sg,
int nents, enum dma_data_direction dir,
-   struct dma_attrs *attrs)
+   unsigned long attrs)
 {
struct pci_dev *pdev = alpha_gendev_to_pci(dev);
struct scatterlist *start, *end, *out;
@@ -729,7 +729,7 @@ static int alpha_pci_map_sg(struct device *dev, struct 
scatterlist *sg,
 
 static void alpha_pci_unmap_sg(struct device *dev, struct scatterlist *sg,
   int nents, enum dma_data_direction dir,
-  struct dma_attrs *attrs)
+  unsigned long attrs)
 {
struct pci_dev *pdev = alpha_gendev_to_pci(dev);
unsigned long flags;
-- 
1.9.1


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


[Xen-devel] [RFC v3 05/45] ARM: dma-mapping: Use unsigned long for dma_attrs

2016-06-02 Thread Krzysztof Kozlowski
Split out subsystem specific changes for easier reviews. This will be
squashed with main commit.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/arm/common/dmabounce.c  |  4 +-
 arch/arm/include/asm/dma-mapping.h   | 13 +++--
 arch/arm/include/asm/xen/page-coherent.h | 16 +++
 arch/arm/mm/dma-mapping.c| 81 
 arch/arm/xen/mm.c|  4 +-
 5 files changed, 56 insertions(+), 62 deletions(-)

diff --git a/arch/arm/common/dmabounce.c b/arch/arm/common/dmabounce.c
index 1143c4d5c567..301281645d08 100644
--- a/arch/arm/common/dmabounce.c
+++ b/arch/arm/common/dmabounce.c
@@ -310,7 +310,7 @@ static inline void unmap_single(struct device *dev, struct 
safe_buffer *buf,
  */
 static dma_addr_t dmabounce_map_page(struct device *dev, struct page *page,
unsigned long offset, size_t size, enum dma_data_direction dir,
-   struct dma_attrs *attrs)
+   unsigned long attrs)
 {
dma_addr_t dma_addr;
int ret;
@@ -344,7 +344,7 @@ static dma_addr_t dmabounce_map_page(struct device *dev, 
struct page *page,
  * should be)
  */
 static void dmabounce_unmap_page(struct device *dev, dma_addr_t dma_addr, 
size_t size,
-   enum dma_data_direction dir, struct dma_attrs *attrs)
+   enum dma_data_direction dir, unsigned long attrs)
 {
struct safe_buffer *buf;
 
diff --git a/arch/arm/include/asm/dma-mapping.h 
b/arch/arm/include/asm/dma-mapping.h
index a83570f10124..d009f7911ffc 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -5,7 +5,6 @@
 
 #include 
 #include 
-#include 
 #include 
 
 #include 
@@ -174,7 +173,7 @@ static inline void dma_mark_clean(void *addr, size_t size) 
{ }
  * to be the device-viewed address.
  */
 extern void *arm_dma_alloc(struct device *dev, size_t size, dma_addr_t *handle,
-  gfp_t gfp, struct dma_attrs *attrs);
+  gfp_t gfp, unsigned long attrs);
 
 /**
  * arm_dma_free - free memory allocated by arm_dma_alloc
@@ -191,7 +190,7 @@ extern void *arm_dma_alloc(struct device *dev, size_t size, 
dma_addr_t *handle,
  * during and after this call executing are illegal.
  */
 extern void arm_dma_free(struct device *dev, size_t size, void *cpu_addr,
-dma_addr_t handle, struct dma_attrs *attrs);
+dma_addr_t handle, unsigned long attrs);
 
 /**
  * arm_dma_mmap - map a coherent DMA allocation into user space
@@ -208,7 +207,7 @@ extern void arm_dma_free(struct device *dev, size_t size, 
void *cpu_addr,
  */
 extern int arm_dma_mmap(struct device *dev, struct vm_area_struct *vma,
void *cpu_addr, dma_addr_t dma_addr, size_t size,
-   struct dma_attrs *attrs);
+   unsigned long attrs);
 
 /*
  * This can be called during early boot to increase the size of the atomic
@@ -262,16 +261,16 @@ extern void dmabounce_unregister_dev(struct device *);
  * The scatter list versions of the above methods.
  */
 extern int arm_dma_map_sg(struct device *, struct scatterlist *, int,
-   enum dma_data_direction, struct dma_attrs *attrs);
+   enum dma_data_direction, unsigned long attrs);
 extern void arm_dma_unmap_sg(struct device *, struct scatterlist *, int,
-   enum dma_data_direction, struct dma_attrs *attrs);
+   enum dma_data_direction, unsigned long attrs);
 extern void arm_dma_sync_sg_for_cpu(struct device *, struct scatterlist *, int,
enum dma_data_direction);
 extern void arm_dma_sync_sg_for_device(struct device *, struct scatterlist *, 
int,
enum dma_data_direction);
 extern int arm_dma_get_sgtable(struct device *dev, struct sg_table *sgt,
void *cpu_addr, dma_addr_t dma_addr, size_t size,
-   struct dma_attrs *attrs);
+   unsigned long attrs);
 
 #endif /* __KERNEL__ */
 #endif
diff --git a/arch/arm/include/asm/xen/page-coherent.h 
b/arch/arm/include/asm/xen/page-coherent.h
index 9408a994cc91..95ce6ac3a971 100644
--- a/arch/arm/include/asm/xen/page-coherent.h
+++ b/arch/arm/include/asm/xen/page-coherent.h
@@ -2,15 +2,14 @@
 #define _ASM_ARM_XEN_PAGE_COHERENT_H
 
 #include 
-#include 
 #include 
 
 void __xen_dma_map_page(struct device *hwdev, struct page *page,
 dma_addr_t dev_addr, unsigned long offset, size_t size,
-enum dma_data_direction dir, struct dma_attrs *attrs);
+enum dma_data_direction dir, unsigned long attrs);
 void __xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
size_t size, enum dma_data_direction dir,
-   struct dma_attrs *attrs);
+   unsigned long attrs);
 void __xen_dma_sync_single_for_cpu(struct device *hwdev,
dma_addr_t handle, size_t size, enum dma_data_direction dir);
 
@@ -18,22 +17,20 @@ 

  1   2   3   >