Re: [Xen-devel] [PATCH] dm_op: Add xendevicemodel_modified_memory_bulk.

2017-03-20 Thread Jan Beulich 
>>> On 16.03.17 at 15:44,  wrote:
> --- a/xen/arch/x86/hvm/dm.c
> +++ b/xen/arch/x86/hvm/dm.c
> @@ -119,56 +119,96 @@ static int set_isa_irq_level(struct domain *d, uint8_t 
> isa_irq,
>  }
>  
>  static int modified_memory(struct domain *d,
> -   struct xen_dm_op_modified_memory *data)
> +   struct xen_dm_op_modified_memory *header,
> +   xen_dm_op_buf_t* buf)
>  {
> -xen_pfn_t last_pfn = data->first_pfn + data->nr - 1;
> -unsigned int iter = 0;
> -int rc = 0;
> +/* Process maximum of 255 pfns before checking for continuation */
> +const uint32_t max_pfns = 0xff;
>  
> -if ( (data->first_pfn > last_pfn) ||
> - (last_pfn > domain_get_maximum_gpfn(d)) )
> -return -EINVAL;
> +xen_pfn_t last_pfn;
> +int rc = 0;
> +uint32_t offset = header->offset;
> +unsigned long pfn;
> +unsigned long max_pfn;
> +unsigned max_nr;
> +uint32_t rem_pfns = max_pfns;

Please avoid fixed width types when you don't really need them. Also
"unsigned int" please instead of plain "unsigned".

>  if ( !paging_mode_log_dirty(d) )
>  return 0;
>  
> -while ( iter < data->nr )
> +if ( (buf->size / sizeof(struct xen_dm_op_modified_memory_extent)) <
> +header->nr_extents )

Indentation.

> +return -EINVAL;
> +
> +while ( offset < header->nr_extents )
>  {
> -unsigned long pfn = data->first_pfn + iter;
> -struct page_info *page;
> +struct xen_dm_op_modified_memory_extent extent;
>  
> -page = get_page_from_gfn(d, pfn, NULL, P2M_UNSHARE);
> -if ( page )
> +if ( copy_from_guest_offset(, buf->h, offset, 1) )
> +return -EFAULT;
> +
> +last_pfn = extent.first_pfn + extent.nr - 1;
> +
> +if ( last_pfn > domain_get_maximum_gpfn(d) )

Where did the original "(data->first_pfn > last_pfn)" go?

> +return -EINVAL;
> +
> +if ( extent.nr > rem_pfns )
> +   max_nr = rem_pfns;
> +else
>  {
> -mfn_t gmfn = _mfn(page_to_mfn(page));
> -
> -paging_mark_dirty(d, gmfn);
> -/*
> - * These are most probably not page tables any more
> - * don't take a long time and don't die either.
> - */
> -sh_remove_shadows(d, gmfn, 1, 0);
> -put_page(page);
> +max_nr = extent.nr;
> +offset++;
>  }
>  
> -iter++;
> +rem_pfns -= max_nr;
> +max_pfn = extent.first_pfn + max_nr;
>  
> -/*
> - * Check for continuation every 256th iteration and if the
> - * iteration is not the last.
> - */
> -if ( (iter < data->nr) && ((iter & 0xff) == 0) &&
> - hypercall_preempt_check() )
> +pfn = extent.first_pfn;
> +while ( pfn < max_pfn )

The max_ prefixes chosen are somewhat problematic with a loop
condition like this: "max" commonly means the maximum valid one
rather than the first following item. Perhaps "end_pfn" and just
"nr"?

>  {
> -data->first_pfn += iter;
> -data->nr -= iter;
> +struct page_info *page;
> +page = get_page_from_gfn(d, pfn, NULL, P2M_UNSHARE);
> +
> +if ( page )
> +{
> +mfn_t gmfn = _mfn(page_to_mfn(page));
> +
> +paging_mark_dirty(d, gmfn);
> +/*
> + * These are most probably not page tables any more
> + * don't take a long time and don't die either.
> + */
> +sh_remove_shadows(d, gmfn, 1, 0);
> +put_page(page);
> +}
> +pfn++;
> +}
>  
> -rc = -ERESTART;
> -break;
> +if ( max_nr < extent.nr )
> +{
> +extent.first_pfn += max_nr;
> +extent.nr-= max_nr;
> +if ( copy_to_guest_offset(buf->h, offset, , 1) )
> +return -EFAULT;

Is this copying back needed when not returning -ERESTART below?
I do realize that with the current code structure it's needed for the
copy_from above to read back the value, but even if this doesn't
look to be a double fetch vulnerability I think it would be better if
the value propagation would occur without going through guest
memory.

>  }
> -}
>  
> -return rc;
> +/*
> + * Check for continuation every 256th pfn and if the
> + * pfn is not the last.
> + */
> +
> +if ( (rem_pfns == 0) && (offset <= header->nr_extents) )

DYM < instead of <= here?

> +{
> +if ( hypercall_preempt_check() )
> +{
> +header->offset = offset;
> +rc = -ERESTART;
> +break;
> +}
> +rem_pfns += max_pfns;

rem_pfns is zero prior to this anyway: Please use

[Xen-devel] [ovmf test] 106782: all pass - PUSHED

2017-03-20 Thread osstest service owner 
flight 106782 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106782/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 3df29b5d16d39b335b7daca625b3781e1da9920c
baseline version:
 ovmf 032862642d7184f7ab335b1c38b43d86c79349f5

Last test of basis   106779  2017-03-20 02:46:19 Z0 days
Testing same since   106782  2017-03-20 07:15:28 Z0 days1 attempts


People who touched revisions under test:
  Dandan Bi 

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



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

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

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

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


Pushing revision :

+ branch=ovmf
+ revision=3df29b5d16d39b335b7daca625b3781e1da9920c
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 
3df29b5d16d39b335b7daca625b3781e1da9920c
+ branch=ovmf
+ revision=3df29b5d16d39b335b7daca625b3781e1da9920c
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.8-testing
+ '[' x3df29b5d16d39b335b7daca625b3781e1da9920c = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ :

[Xen-devel] [PATCH V2] common/mem_access: merged mem_access setting interfaces

2017-03-20 Thread Razvan Cojocaru 
xc_altp2m_set_mem_access() and xc_set_mem_access() end up doing the same thing
in the hypervisor, but the former is a HVMOP and the latter a DOMCTL. Since
nobody is currently using, or has stated intent to use, this functionality
specifically as an HVMOP, this patch removes the HVMOP while adding an extra
parameter to the more flexible DOMCTL variant, in which the altp2m view can be
transmitted (0 for the default view, or when altp2m is disabled).
The xen-access test has been updated in the process.

Signed-off-by: Razvan Cojocaru 

---
Changes since V1:
 - Removed XEN_DOMCTL_INTERFACE_VERSION bump (as the "x86: remove PVHv1
   code" already does this for this release).
 - Replaced uint16_t pad; with uint16_t pad[3]; as suggested by Tamas.
---
 tools/libxc/include/xenctrl.h   | 10 +++---
 tools/libxc/xc_altp2m.c | 25 -
 tools/libxc/xc_mem_access.c | 14 +-
 tools/tests/xen-access/xen-access.c | 25 -
 xen/arch/x86/hvm/hvm.c  | 10 --
 xen/common/mem_access.c |  4 ++--
 xen/include/public/hvm/hvm_op.h | 15 +--
 xen/include/public/memory.h |  2 ++
 8 files changed, 25 insertions(+), 80 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 2d97d36..10d80b3 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1923,9 +1923,6 @@ int xc_altp2m_destroy_view(xc_interface *handle, domid_t 
domid,
 /* Switch all vCPUs of the domain to the specified altp2m view */
 int xc_altp2m_switch_to_view(xc_interface *handle, domid_t domid,
  uint16_t view_id);
-int xc_altp2m_set_mem_access(xc_interface *handle, domid_t domid,
- uint16_t view_id, xen_pfn_t gfn,
- xenmem_access_t access);
 int xc_altp2m_change_gfn(xc_interface *handle, domid_t domid,
  uint16_t view_id, xen_pfn_t old_gfn,
  xen_pfn_t new_gfn);
@@ -1956,9 +1953,8 @@ int xc_mem_paging_load(xc_interface *xch, domid_t 
domain_id,
  * Allowed types are XENMEM_access_default, XENMEM_access_n, any combination of
  * XENMEM_access_ + (rwx), and XENMEM_access_rx2rw
  */
-int xc_set_mem_access(xc_interface *xch, domid_t domain_id,
-  xenmem_access_t access, uint64_t first_pfn,
-  uint32_t nr);
+int xc_set_mem_access(xc_interface *xch, domid_t domain_id, uint16_t view_id,
+  xenmem_access_t access, uint64_t first_pfn, uint32_t nr);
 
 /*
  * Set an array of pages to their respective access in the access array.
@@ -1966,7 +1962,7 @@ int xc_set_mem_access(xc_interface *xch, domid_t 
domain_id,
  * The same allowed access types as for xc_set_mem_access() apply.
  */
 int xc_set_mem_access_multi(xc_interface *xch, domid_t domain_id,
-uint8_t *access, uint64_t *pages,
+uint16_t view_id, uint8_t *access, uint64_t *pages,
 uint32_t nr);
 
 /*
diff --git a/tools/libxc/xc_altp2m.c b/tools/libxc/xc_altp2m.c
index 0639632..4f44a7b 100644
--- a/tools/libxc/xc_altp2m.c
+++ b/tools/libxc/xc_altp2m.c
@@ -163,31 +163,6 @@ int xc_altp2m_switch_to_view(xc_interface *handle, domid_t 
domid,
 return rc;
 }
 
-int xc_altp2m_set_mem_access(xc_interface *handle, domid_t domid,
- uint16_t view_id, xen_pfn_t gfn,
- xenmem_access_t access)
-{
-int rc;
-DECLARE_HYPERCALL_BUFFER(xen_hvm_altp2m_op_t, arg);
-
-arg = xc_hypercall_buffer_alloc(handle, arg, sizeof(*arg));
-if ( arg == NULL )
-return -1;
-
-arg->version = HVMOP_ALTP2M_INTERFACE_VERSION;
-arg->cmd = HVMOP_altp2m_set_mem_access;
-arg->domain = domid;
-arg->u.set_mem_access.view = view_id;
-arg->u.set_mem_access.hvmmem_access = access;
-arg->u.set_mem_access.gfn = gfn;
-
-rc = xencall2(handle->xcall, __HYPERVISOR_hvm_op, HVMOP_altp2m,
- HYPERCALL_BUFFER_AS_ARG(arg));
-
-xc_hypercall_buffer_free(handle, arg);
-return rc;
-}
-
 int xc_altp2m_change_gfn(xc_interface *handle, domid_t domid,
  uint16_t view_id, xen_pfn_t old_gfn,
  xen_pfn_t new_gfn)
diff --git a/tools/libxc/xc_mem_access.c b/tools/libxc/xc_mem_access.c
index 9536635..4242527 100644
--- a/tools/libxc/xc_mem_access.c
+++ b/tools/libxc/xc_mem_access.c
@@ -25,17 +25,19 @@
 
 int xc_set_mem_access(xc_interface *xch,
   domid_t domain_id,
+  uint16_t view_id,
   xenmem_access_t access,
   uint64_t first_pfn,
   uint32_t nr)
 {
 xen_mem_access_op_t mao =
 {
-.op = XENMEM_access_op_set_access,
-.domid  = domain_id,
-.access = access,
-.pfn= first_pfn,
-

Re: [Xen-devel] [PATCH v10 5/6] passthrough/io: don't migrate pirq when it is delivered through VT-d PI

2017-03-20 Thread Chao Gao 
On Mon, Mar 20, 2017 at 03:18:18AM -0600, Jan Beulich wrote:
 On 20.03.17 at 02:59,  wrote:
>> On Fri, Mar 17, 2017 at 04:43:08AM -0600, Jan Beulich wrote:
>> On 15.03.17 at 06:11,  wrote:
 +if ( iommu_intpost )
 +{
 +vcpu = pi_find_dest_vcpu(d, dest, dest_mode, delivery_mode,
 + pirq_dpci->gmsi.gvec);
>>>
>>>This is now outside of the event_lock-ed region - is this safe?
>> 
>> do you mean it is __inside__ the event_lock-ed region?
>
>Oops, indeed.
>
>> I think it is safe
>> for the functions called by pi_find_dest_vcpu() are almost same with
>> hvm_girq_dest_2_vcpu_id.
>
>The question then needs to be put differently: Is this needed?
>You shouldn't move into a locked region what doesn't need to
>be there.

Yes. For we rely on the result to set @via_pi which needs to be 
protected by the lock.

>
 +}
  spin_unlock(>event_lock);
  if ( dest_vcpu_id >= 0 )
  hvm_migrate_pirqs(d->vcpu[dest_vcpu_id]);
>>>
>>>(continuing from above) This could then use vcpu too.
>> 
>> I don't understand. In this patch, vcpu is always null when VT-d PI is not
>> enabled. Do you mean something like below: 
>> 
>> if ( dest_vcpu_id >= 0 )
>> vcpu = d->vcpu[dest_vcpu_id];
>> if ( iommu_intpost && (!vcpu) && (delivery_mode == dest_LowestPrio) )
>> {
>> vcpu = vector_hashing_dest(d, dest, dest_mode,pirq_dpci->gmsi.gvec);
>> ...
>> }
>> spin_unlock(>event_lock);
>> if ( vcpu )
>> hvm_migrate_pirqs(vcpu);
>
>Yes, along these lines, albeit I think the first if() is more complicated
>than it needs to be.

We can make it simple like this:

const struct *vcpu vcpu;
...

vcpu = (dest_vcpu_id >= 0) ? d->vcpu[dest_vcpu_id] : NULL;

Thanks
Chao

>
>Jan
>

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

Re: [Xen-devel] [PATCH v10 5/6] passthrough/io: don't migrate pirq when it is delivered through VT-d PI

2017-03-20 Thread Jan Beulich 
>>> On 20.03.17 at 02:59,  wrote:
> On Fri, Mar 17, 2017 at 04:43:08AM -0600, Jan Beulich wrote:
> On 15.03.17 at 06:11,  wrote:
>>> +if ( iommu_intpost )
>>> +{
>>> +vcpu = pi_find_dest_vcpu(d, dest, dest_mode, delivery_mode,
>>> + pirq_dpci->gmsi.gvec);
>>
>>This is now outside of the event_lock-ed region - is this safe?
> 
> do you mean it is __inside__ the event_lock-ed region?

Oops, indeed.

> I think it is safe
> for the functions called by pi_find_dest_vcpu() are almost same with
> hvm_girq_dest_2_vcpu_id.

The question then needs to be put differently: Is this needed?
You shouldn't move into a locked region what doesn't need to
be there.

>>> +}
>>>  spin_unlock(>event_lock);
>>>  if ( dest_vcpu_id >= 0 )
>>>  hvm_migrate_pirqs(d->vcpu[dest_vcpu_id]);
>>
>>(continuing from above) This could then use vcpu too.
> 
> I don't understand. In this patch, vcpu is always null when VT-d PI is not
> enabled. Do you mean something like below: 
> 
> if ( dest_vcpu_id >= 0 )
> vcpu = d->vcpu[dest_vcpu_id];
> if ( iommu_intpost && (!vcpu) && (delivery_mode == dest_LowestPrio) )
> {
> vcpu = vector_hashing_dest(d, dest, dest_mode,pirq_dpci->gmsi.gvec);
> ...
> }
> spin_unlock(>event_lock);
> if ( vcpu )
> hvm_migrate_pirqs(vcpu);

Yes, along these lines, albeit I think the first if() is more complicated
than it needs to be.

Jan


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

Re: [Xen-devel] [PATCH v2 9/9] x86/pagewalk: non-functional cleanup

2017-03-20 Thread Jan Beulich 
 >>> On 16.03.17 at 17:31,  wrote:
> * Drop trailing whitespace
>  * Consistently apply Xen style
>  * Introduce a local variable block
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 



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

Re: [Xen-devel] [PATCH v2 8/9] x86/pagewalk: Improve the logic behind setting access and dirty bits

2017-03-20 Thread Jan Beulich 
>>> On 16.03.17 at 17:31,  wrote:
> @@ -413,24 +417,33 @@ guest_walk_tables(struct vcpu *v, struct p2m_domain 
> *p2m,
>   * success.  Although the PRMs say higher-level _PAGE_ACCESSED bits
>   * get set whenever a lower-level PT is used, at least some hardware
>   * walkers behave this way. */
> -#if GUEST_PAGING_LEVELS == 4 /* 64-bit only... */
> -if ( set_ad_bits(l4p + guest_l4_table_offset(va), >l4e, 0) )
> -paging_mark_dirty(d, gw->l4mfn);
> -if ( set_ad_bits(l3p + guest_l3_table_offset(va), >l3e,
> - (pse1G && (walk & PFEC_write_access))) )
> -paging_mark_dirty(d, gw->l3mfn);
> -#endif
> -if ( !pse1G )
> +switch ( leaf_level )
>  {
> +default:
> +ASSERT_UNREACHABLE();
> +break;
> +
> +case 1:
> +if ( set_ad_bits(l1p + guest_l1_table_offset(va), >l1e,
> + (walk & PFEC_write_access) && leaf_level == 1) )

The comparison on leaf_level is pointless here (other than further
down).

> +paging_mark_dirty(d, gw->l1mfn);
> +/* Fallthrough */
> +
> +case 2:
>  if ( set_ad_bits(l2p + guest_l2_table_offset(va), >l2e,
> - (pse2M && (walk & PFEC_write_access))) )
> + (walk & PFEC_write_access) && leaf_level == 2) )
>  paging_mark_dirty(d, gw->l2mfn);
> -if ( !pse2M )
> -{
> -if ( set_ad_bits(l1p + guest_l1_table_offset(va), >l1e,
> - (walk & PFEC_write_access)) )
> -paging_mark_dirty(d, gw->l1mfn);
> -}
> +/* Fallthrough */
> +
> +#if GUEST_PAGING_LEVELS == 4 /* 64-bit only... */
> +case 3:
> +if ( set_ad_bits(l3p + guest_l3_table_offset(va), >l3e,
> + (walk & PFEC_write_access) && leaf_level == 3) )
> +paging_mark_dirty(d, gw->l3mfn);
> +
> +if ( set_ad_bits(l4p + guest_l4_table_offset(va), >l4e, 0) )

false

Other than that,
Reviewed-by: Jan Beulich 

Personally I also think the fall through behavior would be more
immediately visible if you omitted the blank lines between the case
blocks.

Jan


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

Re: [Xen-devel] [PATCH v10 5/6] passthrough/io: don't migrate pirq when it is delivered through VT-d PI

2017-03-20 Thread Chao Gao 
On Fri, Mar 17, 2017 at 04:43:08AM -0600, Jan Beulich wrote:
 On 15.03.17 at 06:11,  wrote:
>> @@ -441,6 +442,15 @@ int pt_irq_create_bind(
>>  
>>  dest_vcpu_id = hvm_girq_dest_2_vcpu_id(d, dest, dest_mode);
>>  pirq_dpci->gmsi.dest_vcpu_id = dest_vcpu_id;
>> +
>> +pirq_dpci->gmsi.via_pi = 0;
>
>false
>
>> +if ( iommu_intpost )
>> +{
>> +vcpu = pi_find_dest_vcpu(d, dest, dest_mode, delivery_mode,
>> + pirq_dpci->gmsi.gvec);
>
>This is now outside of the event_lock-ed region - is this safe?

do you mean it is __inside__ the event_lock-ed region? I think it is safe
for the functions called by pi_find_dest_vcpu() are almost same with
hvm_girq_dest_2_vcpu_id.

>
>Furthermore, looking at this, why do we need to call this function
>at all in other than the LowestPrio case? It looks as if we could
>easily use what hvm_girq_dest_2_vcpu_id() provides in the Fixed
>case.

Agree. we can delete pi_find_dest_vcpu() and for LowestPrio case 
when VT-d PI enabled, we call vector_hashing_dest() directly.

>
>> +if ( vcpu )
>> +pirq_dpci->gmsi.via_pi = 1;
>
>true
>
>> +}
>>  spin_unlock(>event_lock);
>>  if ( dest_vcpu_id >= 0 )
>>  hvm_migrate_pirqs(d->vcpu[dest_vcpu_id]);
>
>(continuing from above) This could then use vcpu too.

I don't understand. In this patch, vcpu is always null when VT-d PI is not
enabled. Do you mean something like below: 

if ( dest_vcpu_id >= 0 )
vcpu = d->vcpu[dest_vcpu_id];
if ( iommu_intpost && (!vcpu) && (delivery_mode == dest_LowestPrio) )
{
vcpu = vector_hashing_dest(d, dest, dest_mode,pirq_dpci->gmsi.gvec);
...
}
spin_unlock(>event_lock);
if ( vcpu )
hvm_migrate_pirqs(vcpu);

Thank,
Chao

>
>> --- a/xen/include/xen/hvm/irq.h
>> +++ b/xen/include/xen/hvm/irq.h
>> @@ -63,6 +63,7 @@ struct hvm_gmsi_info {
>>  uint32_t gvec;
>>  uint32_t gflags;
>>  int dest_vcpu_id; /* -1 :multi-dest, non-negative: dest_vcpu_id */
>> +bool via_pi; /* directly deliver to guest via VT-d PI? */
>
>Wouldn't the field name perhaps better be (or include) "posted"?
>
>Jan
>

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

[Xen-devel] [PATCH v4] displif: add ABI for para-virtual display

2017-03-20 Thread Oleksandr Andrushchenko 
From: Oleksandr Andrushchenko 

This is the ABI for the two halves of a para-virtualized
display driver.

This protocol aims to provide a unified protocol which fits more
sophisticated use-cases than a framebuffer device can handle. At the
moment basic functionality is supported with the intention to extend:
  o multiple dynamically allocated/destroyed framebuffers
  o buffers of arbitrary sizes
  o better configuration options including multiple display support

Note: existing fbif can be used together with displif running at the
same time, e.g. on Linux one provides framebuffer and another DRM/KMS

Future extensions to the existing protocol may include:
  o allow display/connector cloning
  o allow allocating objects other than display buffers
  o add planes/overlays support
  o support scaling
  o support rotation

Thank you,
Oleksandr Andrushchenko
Oleksandr Grytsov

Oleksandr Andrushchenko (1):
  displif: add ABI for para-virtual display

 xen/include/public/io/displif.h | 847 
 1 file changed, 847 insertions(+)
 create mode 100644 xen/include/public/io/displif.h

-- 
2.7.4


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

[Xen-devel] [PATCH v4] displif: add ABI for para-virtual display

2017-03-20 Thread Oleksandr Andrushchenko 
From: Oleksandr Andrushchenko 

This is the ABI for the two halves of a para-virtualized
display driver.

This protocol aims to provide a unified protocol which fits more
sophisticated use-cases than a framebuffer device can handle. At the
moment basic functionality is supported with the intention to extend:
  o multiple dynamically allocated/destroyed framebuffers
  o buffers of arbitrary sizes
  o better configuration options including multiple display support

Note: existing fbif can be used together with displif running at the
same time, e.g. on Linux one provides framebuffer and another DRM/KMS

Future extensions to the existing protocol may include:
  o allow display/connector cloning
  o allow allocating objects other than display buffers
  o add planes/overlays support
  o support scaling
  o support rotation

Note, that this protocol doesn't use ring macros for
bi-directional exchange (PV calls/9pfs) bacause:
  o it statically defines the use of a single page
for the ring buffer
  o it uses direct memory access to ring's contents
w/o memory copying
  o re-uses the same idea that kbdif/fbif use
which for this use-case seems to be appropriate

==
Rationale for introducing this protocol instead of
using the existing fbif:
==

1. In/out event sizes
  o fbif - 40 octets
  o displif - 40 octets
This is only the initial version of the displif protocol
which means that there could be requests which will not fit
(WRT introducing some GPU related functionality
later on). In that case we cannot alter fbif sizes as we need to
be backward compatible an will be forced to handle those
apart of fbif.

2. Shared page
Displif doesn't use anything like struct xenfb_page, but
DEFINE_RING_TYPES(xen_displif, struct xendispl_req, struct
xendispl_resp) which is a better and more common way.
Output events use a shared page which only has in_cons and in_prod
and all the rest is used for incoming events. Here struct xenfb_page
could probably be used as is despite the fact that it only has a half
of a page for incoming events which is only 50 events. (consider
something like 60Hz display)

3. Amount of changes.
fbif only provides XENFB_TYPE_UPDATE and XENFB_TYPE_RESIZE
events, so it looks like it is easier to get fb support into displif
than vice versa. displif at the moment has 6 requests and 1 event,
multiple connector support, etc.

---
Changes since v3:
 * add clarification on buffer's size/depth/format and
   connector's resolution
 * move be_alloc feature into domain's configuration
   to allow more use-cases and freedom (e.g. for 1:1
   mapped domains there may be no need to request backend
   to allocate buffers, while for the rest it may make more
   sense)
 * rename XenStore entries:
 ctrl-ring-ref -> req-ring-ref
 ctrl-channel -> req-event-channel
 event-ring-ref -> evt-ring-ref
 event-channel -> evt-event-channel
 * have 2 separate sections for req/resp and evt transport
   parameters
 * fix and extend recovery flow description
 * reserve request codes for future fbif integration if need be
   (request codes [0; 15] are reserved)
 * error on attempt to create multiple buffers with same cookie(s)
 * clarification of page directory usage for be_alloc feature
 * add editor's block

Changes since v2:
 * updated XenStore configuration template/pattern
 * added "Recovery flow" to state diagram description
 * renamed gref_directory_start to gref_directory
 * added missing "versions" and "version" string constants

Changes since v1:
 * fixed xendispl_event_page padding size
 * added versioning support
 * explicitly define value types for XenStore fields
 * text decoration re-work
 * added offsets to ASCII box notation

Changes since initial:
 * DRM changed to DISPL, protocol made generic
 * major re-work addressing issues raised for sndif

Signed-off-by: Oleksandr Grytsov 
Signed-off-by: Oleksandr Andrushchenko 
---
 xen/include/public/io/displif.h | 847 
 1 file changed, 847 insertions(+)
 create mode 100644 xen/include/public/io/displif.h

diff --git a/xen/include/public/io/displif.h b/xen/include/public/io/displif.h
new file mode 100644
index ..ac55c4fe8bbe
--- /dev/null
+++ b/xen/include/public/io/displif.h
@@ -0,0 +1,847 @@
+/**
+ * displif.h
+ *
+ * Unified display device I/O interface for Xen guest OSes.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit

Re: [Xen-devel] [PATCH v2 7/9] x86/shadow: Use the pagewalk reserved bits helpers

2017-03-20 Thread Jan Beulich 
>>> On 16.03.17 at 17:31,  wrote:
> The shadow logic should not create a valid/present shadow of a guest PTE which
> contains reserved bits from the guests point of view.  It is not guaranteed
> that the hardware pagewalk will come to the same conclusion, and raise a
> pagefault.
> 
> Shadows created on demand from the pagefault handler are fine because the
> pagewalk over the guest tables will have injected the fault into the guest
> rather than creating a shadow.
> 
> However, shadows created by sh_resync_l1() and sh_prefetch() haven't undergone
> a pagewalk and need to account for reserved bits before creating the shadow.
> 
> In practice, this means a 3-level guest could previously cause PTEs with bits
> 63:52 set to be shadowed (and discarded).  This PTE should cause #PF[RSVD]
> when encountered by hardware, but the installed shadow is valid and hardware
> doesn't fault.
> 
> Reuse the pagewalk reserved bits helpers, and assert in
> l?e_propagate_from_guest() that shadows are not attempted to be created with
> reserved bits set.
> 
> Signed-off-by: Andrew Cooper 

This looks fine to me, but I can't claim to know the shadow code well
enough to be certain all places where changes are needed are
actually covered. So I'll defer to Tim and George.

Jan


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

Re: [Xen-devel] [PATCH v2 5/9] x86/pagewalk: Helpers for reserved bit handling

2017-03-20 Thread Jan Beulich 
>>> On 16.03.17 at 17:31,  wrote:
> Some bits are unconditionally reserved in pagetable entries, or reserved
> because of alignment restrictions.  Other bits are reserved because of control
> register configuration.
> 
> Introduce helpers which take an individual vcpu and guest pagetable entry, and
> calculates whether any reserved bits are set.
> 
> While here, add a couple of newlines to aid readability.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 
with the same remarks as on the prior patch for ...

> @@ -182,6 +216,21 @@ static inline bool guest_supports_l2_superpages(const 
> struct vcpu *v)
> || (v->arch.hvm_vcpu.guest_cr[4] & X86_CR4_PSE)));
>  }
>  
> +static inline bool guest_supports_pse36(const struct domain *d)
> +{
> +/*
> + * Only called in the context of 2-level guests, after
> + * guest_supports_l2_superpages() has indicated true.
> + *
> + * Once L2 superpages are active, here are no control register settings
> + * for the hardware pagewalk on the subject of PSE36.  If the guest
> + * constructs a PSE36 superpage on capable hardware, it will function
> + * irrespective of whether the feature is advertised.  Xen's model of
> + * performing a pagewalk should match.
> + */
> +return paging_mode_hap(d) && cpu_has_pse36;
> +}

... this.

Jan


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

Re: [Xen-devel] [PATCH v2 4/9] x86/pagewalk: Clean up guest_supports_* predicates

2017-03-20 Thread Jan Beulich 
>>> On 16.03.17 at 17:31,  wrote:
> Switch them to returning bool, and taking const parameters.
> 
> Rename guest_supports_superpages() to guest_supports_l2_superpages() to
> indicate which level of pagetables it is actually referring to, and rename
> guest_supports_1G_superpages() to guest_supports_l3_superpages() for
> consistency.
> 
> guest_supports_l3_superpages() is a static property of the domain, rather than
> control register settings, so is switched to take a domain pointer.
> hvm_pse1gb_supported() is inlined into its sole user because it isn't strictly
> hvm-specific (it is hap-specific) and really should be beside a comment
> explaining why the cpuid policy is ignored.
> 
> While cleaning up part of the file, clean up all trailing whilespace, and fix
> one comment which accidently refered to PG living in CR4 rather than CR0.
> 
> Requested-by: Jan Beulich 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 
with two remarks:

> -static inline int
> -guest_supports_1G_superpages(struct vcpu *v)
> +static inline bool guest_supports_l3_superpages(const struct domain *d)
>  {
> -return (GUEST_PAGING_LEVELS >= 4 && hvm_pse1gb_supported(v->domain));
> +/*
> + * There are no control register settings for the hardware pagewalk on 
> the
> + * subject of 1G superpages.
> + *
> + * If the guest constructs a 1GB superpage on capable hardware, it will
> + * function irrespective of whether the feature is advertised.  Xen's
> + * model of performing a pagewalk should match.
> + */
> +return GUEST_PAGING_LEVELS >= 4 && paging_mode_hap(d) && cpu_has_page1gb;

Is it perhaps worth adding half a sentence stating that shadow
doesn't support 1Gb pages at all?

Also I'm still not really happy with the guest_supports_ prefixes
for this and its L2 counterpart: The question here isn't whether the
guest supports it (we can't know whether it does), but whether it
enabled PSE/PAE/LM. Arguably the L3 case is less clear because
of the mentioned lack of an explicit enabled bit, so I can live with
the patch going in unchanged (the L2 side then simply for things
to remain consistent, albeit there's then already the difference of
parameter types).

Jan


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

Re: [Xen-devel] [Qemu-devel] [PATCH] xen: use libxendevice model to restrict operations

2017-03-20 Thread Paul Durrant 
> -Original Message-
> From: Philippe Mathieu-Daudé [mailto:philippe.mathieu.da...@gmail.com]
> On Behalf Of Philippe Mathieu-Daudé
> Sent: 17 March 2017 21:21
> To: Paul Durrant ; qemu-de...@nongnu.org; xen-
> de...@lists.xenproject.org
> Cc: Anthony Perard ; Paolo Bonzini
> ; Stefano Stabellini 
> Subject: Re: [Qemu-devel] [PATCH] xen: use libxendevice model to restrict
> operations
> 
> Hi Paul,
> 
> On 03/17/2017 10:30 AM, Paul Durrant wrote:
> > This patch adds a command-line option (-xen-domid-restrict) which will
> > use the new libxendevicemodel API to restrict devicemodel operations to
> > the specified domid.
> >
> > This patch also adds a tracepoint to allow successful enabling of the
> > restriction to be monitored.
> >
> > Signed-off-by: Paul Durrant 
> > ---
> > Cc: Stefano Stabellini 
> > Cc: Anthony Perard 
> > Cc: Paolo Bonzini 
> >
> > NOTE: This is already re-based on Juergen Gross's patch "xen: use 5 digit
> >   xen versions" and so should not be applied until after that patch
> >   has been applied.
> > ---
> >  hw/xen/trace-events |  1 +
> >  include/hw/xen/xen.h|  1 +
> >  include/hw/xen/xen_common.h | 23 +++
> >  qemu-options.hx |  6 ++
> >  vl.c|  8 
> >  xen-hvm.c   |  8 
> >  6 files changed, 47 insertions(+)
> >
> > diff --git a/hw/xen/trace-events b/hw/xen/trace-events
> > index c4fb6f1..a5b5e8b 100644
> > --- a/hw/xen/trace-events
> > +++ b/hw/xen/trace-events
> > @@ -11,3 +11,4 @@ xen_map_portio_range(uint32_t id, uint64_t
> start_addr, uint64_t end_addr) "id: %
> >  xen_unmap_portio_range(uint32_t id, uint64_t start_addr, uint64_t
> end_addr) "id: %u start: %#"PRIx64" end: %#"PRIx64
> >  xen_map_pcidev(uint32_t id, uint8_t bus, uint8_t dev, uint8_t func) "id:
> %u bdf: %02x.%02x.%02x"
> >  xen_unmap_pcidev(uint32_t id, uint8_t bus, uint8_t dev, uint8_t func) "id:
> %u bdf: %02x.%02x.%02x"
> > +xen_domid_restrict(void) ""
> > diff --git a/include/hw/xen/xen.h b/include/hw/xen/xen.h
> > index 2b1733b..7efcdaa 100644
> > --- a/include/hw/xen/xen.h
> > +++ b/include/hw/xen/xen.h
> > @@ -21,6 +21,7 @@ enum xen_mode {
> >
> >  extern uint32_t xen_domid;
> >  extern enum xen_mode xen_mode;
> > +extern bool xen_domid_restrict;
> >
> >  extern bool xen_allowed;
> >
> > diff --git a/include/hw/xen/xen_common.h
> b/include/hw/xen/xen_common.h
> > index df098c7..5962bc4 100644
> > --- a/include/hw/xen/xen_common.h
> > +++ b/include/hw/xen/xen_common.h
> > @@ -152,6 +152,13 @@ static inline int xendevicemodel_set_mem_type(
> >  return xc_hvm_set_mem_type(dmod, domid, mem_type, first_pfn, nr);
> >  }
> >
> > +static inline int xendevicemodel_restrict(
> > +xendevicemodel_handle *dmod, domid_t domid)
> > +{
> > +errno = ENOTTY;
> > +return -1;
> > +}
> > +
> >  #else /* CONFIG_XEN_CTRL_INTERFACE_VERSION >= 40900 */
> >
> >  #include 
> > @@ -206,6 +213,22 @@ static inline int xen_modified_memory(domid_t
> domid, uint64_t first_pfn,
> >  return xendevicemodel_modified_memory(xen_dmod, domid,
> first_pfn, nr);
> >  }
> >
> > +static inline int xen_restrict(domid_t domid)
> > +{
> > +int rc = xendevicemodel_restrict(xen_dmod, domid);
> 
> might it be more useful to log the retcode?
> 
> trace_xen_domid_restrict(rc);
> 
> > +
> > +if (rc == 0) {
> > +trace_xen_domid_restrict();
> 
> and drop the previous line.

Actually the retcode is pretty uninteresting but tracing errno would be a good 
idea so I think I'll do that.

Cheers,

  Paul

> 
> > +return 0;
> > +}
> > +
> > +if (errno == ENOTTY) {
> > +return 0;
> > +}
> > +
> > +return rc;
> > +}
> > +
> >  /* Xen 4.2 through 4.6 */
> >  #if CONFIG_XEN_CTRL_INTERFACE_VERSION < 40701
> >
> > diff --git a/qemu-options.hx b/qemu-options.hx
> > index 99af8ed..4aab077 100644
> > --- a/qemu-options.hx
> > +++ b/qemu-options.hx
> > @@ -3354,6 +3354,10 @@ DEF("xen-attach", 0,
> QEMU_OPTION_xen_attach,
> >  "-xen-attach attach to existing xen domain\n"
> >  "xend will use this when starting QEMU\n",
> >  QEMU_ARCH_ALL)
> > +DEF("xen-domid-restrict", 0, QEMU_OPTION_xen_domid_restrict,
> > +"-xen-domid-restrict restrict set of available xen operations\n"
> > +"to specified domain id\n",
> > +QEMU_ARCH_ALL)
> >  STEXI
> >  @item -xen-domid @var{id}
> >  @findex -xen-domid
> > @@ -3366,6 +3370,8 @@ Warning: should not be used when xend is in use
> (XEN only).
> >  @findex -xen-attach
> >  Attach to existing xen domain.
> >  xend will use this when starting QEMU (XEN only).
> > +@findex -xen-domid-restrict
> > +Restrict set of available xen operations to specified domain id (XEN only).
> >  ETEXI
> >

[Xen-devel] Ping#2: [PATCH] AMD-Vi: allocate root table on demand

2017-03-20 Thread Jan Beulich 
Suravee? Or alternatively, Sherry, is Suravee unavailable for an
extended period of time?

Jan

>>> On 10.03.17 at 17:19,  wrote:
 On 03.03.17 at 15:29,  wrote:
>> This was my originally intended fix for the AMD side of XSA-207:
>> There's no need to unconditionally allocate the root table, and with
>> that there's then also no way to leak it when a guest has no devices
>> assigned.
>> 
>> Signed-off-by: Jan Beulich 
>> 
>> --- a/xen/drivers/passthrough/amd/iommu_map.c
>> +++ b/xen/drivers/passthrough/amd/iommu_map.c
>> @@ -636,11 +636,10 @@ int amd_iommu_map_page(struct domain *d,
>>  {
>>  bool_t need_flush = 0;
>>  struct domain_iommu *hd = dom_iommu(d);
>> +int rc;
>>  unsigned long pt_mfn[7];
>>  unsigned int merge_level;
>>  
>> -BUG_ON( !hd->arch.root_table );
>> -
>>  if ( iommu_use_hap_pt(d) )
>>  return 0;
>>  
>> @@ -648,6 +647,13 @@ int amd_iommu_map_page(struct domain *d,
>>  
>>  spin_lock(>arch.mapping_lock);
>>  
>> +rc = amd_iommu_alloc_root(hd);
>> +if ( rc )
>> +{
>> +spin_unlock(>arch.mapping_lock);
>> +return rc;
>> +}
>> +
>>  /* Since HVM domain is initialized with 2 level IO page table,
>>   * we might need a deeper page table for lager gfn now */
>>  if ( is_hvm_domain(d) )
>> @@ -717,8 +723,6 @@ int amd_iommu_unmap_page(struct domain *
>>  unsigned long pt_mfn[7];
>>  struct domain_iommu *hd = dom_iommu(d);
>>  
>> -BUG_ON( !hd->arch.root_table );
>> -
>>  if ( iommu_use_hap_pt(d) )
>>  return 0;
>>  
>> @@ -726,6 +730,12 @@ int amd_iommu_unmap_page(struct domain *
>>  
>>  spin_lock(>arch.mapping_lock);
>>  
>> +if ( !hd->arch.root_table )
>> +{
>> +spin_unlock(>arch.mapping_lock);
>> +return 0;
>> +}
>> +
>>  /* Since HVM domain is initialized with 2 level IO page table,
>>   * we might need a deeper page table for lager gfn now */
>>  if ( is_hvm_domain(d) )
>> --- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
>> +++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
>> @@ -222,23 +222,29 @@ int __init amd_iov_detect(void)
>>  return scan_pci_devices();
>>  }
>>  
>> -static int allocate_domain_resources(struct domain_iommu *hd)
>> +int amd_iommu_alloc_root(struct domain_iommu *hd)
>>  {
>> -/* allocate root table */
>> -spin_lock(>arch.mapping_lock);
>> -if ( !hd->arch.root_table )
>> +if ( unlikely(!hd->arch.root_table) )
>>  {
>>  hd->arch.root_table = alloc_amd_iommu_pgtable();
>>  if ( !hd->arch.root_table )
>> -{
>> -spin_unlock(>arch.mapping_lock);
>>  return -ENOMEM;
>> -}
>>  }
>> -spin_unlock(>arch.mapping_lock);
>> +
>>  return 0;
>>  }
>>  
>> +static int __must_check allocate_domain_resources(struct domain_iommu *hd)
>> +{
>> +int rc;
>> +
>> +spin_lock(>arch.mapping_lock);
>> +rc = amd_iommu_alloc_root(hd);
>> +spin_unlock(>arch.mapping_lock);
>> +
>> +return rc;
>> +}
>> +
>>  static int get_paging_mode(unsigned long entries)
>>  {
>>  int level = 1;
>> @@ -259,14 +265,6 @@ static int amd_iommu_domain_init(struct
>>  {
>>  struct domain_iommu *hd = dom_iommu(d);
>>  
>> -/* allocate page directroy */
>> -if ( allocate_domain_resources(hd) != 0 )
>> -{
>> -if ( hd->arch.root_table )
>> -free_domheap_page(hd->arch.root_table);
>> -return -ENOMEM;
>> -}
>> -
>>  /* For pv and dom0, stick with get_paging_mode(max_page)
>>   * For HVM dom0, use 2 level page table at first */
>>  hd->arch.paging_mode = is_hvm_domain(d) ?
>> @@ -280,6 +278,9 @@ static void __hwdom_init amd_iommu_hwdom
>>  unsigned long i; 
>>  const struct amd_iommu *iommu;
>>  
>> +if ( allocate_domain_resources(dom_iommu(d)) )
>> +BUG();
>> +
>>  if ( !iommu_passthrough && !need_iommu(d) )
>>  {
>>  int rc = 0;
>> @@ -363,7 +364,7 @@ static int reassign_device(struct domain
>> u8 devfn, struct pci_dev *pdev)
>>  {
>>  struct amd_iommu *iommu;
>> -int bdf;
>> +int bdf, rc;
>>  struct domain_iommu *t = dom_iommu(target);
>>  
>>  bdf = PCI_BDF2(pdev->bus, pdev->devfn);
>> @@ -385,10 +386,9 @@ static int reassign_device(struct domain
>>  pdev->domain = target;
>>  }
>>  
>> -/* IO page tables might be destroyed after pci-detach the last device
>> - * In this case, we have to re-allocate root table for next 
> pci-attach.*/
>> -if ( t->arch.root_table == NULL )
>> -allocate_domain_resources(t);
>> +rc = allocate_domain_resources(t);
>> +if ( rc )
>> +return rc;
>>  
>>  amd_iommu_setup_domain_device(target, iommu, devfn, pdev);
>>  AMD_IOMMU_DEBUG("Re-assign %04x:%02x:%02x.%u from dom%d to dom%d\n",
>> --- a/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
>> +++

Re: [Xen-devel] [PATCH v3] x86/time: Don't use virtual TSC if host and guest frequencies are equal

2017-03-20 Thread Jan Beulich 
>>> On 17.03.17 at 19:15,  wrote:
> Commit 82713ec8d2 ("x86: use native RDTSC(P) execution when guest and
> host frequencies are the same") left out optimization for PV guests
> when host and guest run at the same frequency.
> 
> For such a case we should be able not to use virtual TSC regardless
> of whether we are runing before or after a migration (i.e. regardless
> of incarnation value).
> 
> Signed-off-by: Boris Ostrovsky 
> Suggested-by: Jan Beulich 

Reviewed-by: Jan Beulich 



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

Re: [Xen-devel] [PATCH v2 1/2] xen: sched: don't call hooks of the wrong scheduler via VCPU2OP

2017-03-20 Thread Jan Beulich 
>>> On 17.03.17 at 19:29,  wrote:
> On 17/03/17 19:19, Dario Faggioli wrote:
>> Within context_saved(), we call the context_saved hook,
>> and we use VCPU2OP() to determine from what scheduler.
>> VCPU2OP uses DOM2OP, which uses d->cpupool, which is
>> NULL when d is the idle domain. And in that case,
>> DOM2OP just returns ops, the scheduler of cpupool0.
>> 
>> Therefore, if:
>> - cpupool0's scheduler defines context_saved (like
>>   Credit2 and RTDS do),
>> - we are not in cpupool0 (i.e., our scheduler is
>>   not ops),
>> - we are context switching from idle,
>> 
>> we call VCPU2OP(idle_vcpu), which means
>> DOM2OP(idle->cpupool), which is ops.
>> 
>> Therefore, we both:
>> - check if context_saved is defined in the wrong
>>   scheduler;
>> - if yes, call the wrong one.
>> 
>> When using Credit2 at boot, and also Credit2 in
>> the other cpupool, this is wrong but innocuous,
>> because it only involves the idle vcpus.
>> 
>> When using Credit2 at boot, and Credit1 in the
>> other cpupool, this is *totally* wrong, and
>> it's by chance it does not explode!
>> 
>> When using Credit2 and other schedulers I'm
>> developping, I hit the following assert (in
>> sched_credit2.c, on a CPU inside a cpupool that
>> does not use Credit2):
>> 
>> csched2_context_saved()
>> {
>>  ...
>>  ASSERT(!vcpu_on_runq(svc));
>>  ...
>> }
>> 
>> Fix this by dealing explicitly, in VCPU2OP, with
>> idle vcpus, returning the scheduler of the pCPU
>> they (always) run on.
>> 
>> While there, rename VCPU2OP itself to something
>> that makes it easier to understand what it does.
>> 
>> Signed-off-by: Dario Faggioli 
> 
> Reviewed-by: Juergen Gross 

This came through twice, so I'm now wondering whether one of
them was meant for 2/2, or whether this was just some
infrastructure glitch.

Jan


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

[Xen-devel] [PATCH 1/2] xenstore: set correct error code when violating quota

2017-03-20 Thread Juergen Gross 
When the number of permitted xenstore entries for a domain is being
exceeded the operation trying to create a new entry is denied.
Unfortunately errno isn't being set in this case so the error code
returned to the client is undefined.

Set errno to ENOSPC in this case.

Signed-off-by: Juergen Gross 
---
This is a backport candidate.
---
 tools/xenstore/xenstored_core.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index 5c659d8..ed80345 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -937,8 +937,10 @@ static struct node *construct_node(struct connection 
*conn, const void *ctx,
if (!parent)
return NULL;
 
-   if (domain_entry(conn) >= quota_nb_entry_per_domain)
+   if (domain_entry(conn) >= quota_nb_entry_per_domain) {
+   errno = ENOSPC;
return NULL;
+   }
 
/* Add child to parent. */
base = basename(name);
-- 
2.10.2


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

[Xen-devel] [PATCH 0/2] xensore: fixing two bugs

2017-03-20 Thread Juergen Gross 
Two small patches to fix bugs: one error path correction (setting
correct error code for caller) and add some missing checks for
allocation failures.

Juergen Gross (2):
  xenstore: set correct error code when violating quota
  xenstore: add missing checks for allocation failure

 tools/xenstore/xenstored_core.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

-- 
2.10.2


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

[Xen-devel] [PATCH 2/2] xenstore: add missing checks for allocation failure

2017-03-20 Thread Juergen Gross 
Add a missing allocation failure checks.

Signed-off-by: Juergen Gross 
---
 tools/xenstore/xenstored_core.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index ed80345..fe11ff2 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -946,6 +946,8 @@ static struct node *construct_node(struct connection *conn, 
const void *ctx,
base = basename(name);
baselen = strlen(base) + 1;
children = talloc_array(ctx, char, parent->childlen + baselen);
+   if (!children)
+   goto nomem;
memcpy(children, parent->children, parent->childlen);
memcpy(children + parent->childlen, base, baselen);
parent->children = children;
@@ -953,13 +955,19 @@ static struct node *construct_node(struct connection 
*conn, const void *ctx,
 
/* Allocate node */
node = talloc(ctx, struct node);
+   if (!node)
+   goto nomem;
node->tdb = tdb_context(conn);
node->name = talloc_strdup(node, name);
+   if (!node->name)
+   goto nomem;
 
/* Inherit permissions, except unprivileged domains own what they 
create */
node->num_perms = parent->num_perms;
node->perms = talloc_memdup(node, parent->perms,
node->num_perms * sizeof(node->perms[0]));
+   if (!node->perms)
+   goto nomem;
if (domain_is_unprivileged(conn))
node->perms[0].id = conn->id;
 
@@ -969,6 +977,10 @@ static struct node *construct_node(struct connection 
*conn, const void *ctx,
node->parent = parent;
domain_entry_inc(conn, node);
return node;
+
+nomem:
+   errno = ENOMEM;
+   return NULL;
 }
 
 static int destroy_node(void *_node)
-- 
2.10.2


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

Re: [Xen-devel] question: xen/qemu - mmio mapping issues for device pass-through

2017-03-20 Thread Jan Beulich 
>>> On 20.03.17 at 02:58,  wrote:
> On March 16, 2017 11:32 PM, Jan Beulich wrote:
> On 16.03.17 at 15:21,  wrote:
>>> On March 16, 2017 10:06 PM, Jan Beulich wrote:
>>> On 16.03.17 at 14:55,  wrote:
> I try to pass-through a device with 8G large bar, such as nvidia
> M60(note1, pci-e info as below). It takes about '__15 sconds__' to
> update 8G large bar in QEMU::xen_pt_region_update()..
> Specifically, it is xc_domain_memory_mapping() in
>>xen_pt_region_update().
>
> Digged into xc_domain_memory_mapping(), I find it mainly call
> "do_domctl
> （…case XEN_DOMCTL_memory_mapping…）"
> to mapping mmio region.. of cause, I find out that this mapping
> could take a while in the code comment below ' case
XEN_DOMCTL_memory_mapping '.
>
> my questions:
> 1. could we make this mapping mmio region quicker?

>>>
>>> Thanks for your quick reply.
>>>
Yes, e.g. by using large (2M or 1G) pages. This has been on my todo
list for quite a while...

> 2. if could not, does it limit by hardware performance?

I'm afraid I don't understand the question. If you mean "Is it limited
by hw performance", then no, see above. If you mean "Does it limit hw
performance", then again no, I don't think so (other than the effect
of having more IOMMU translation levels than really necessary for such
>>large a region).

>>>
>>> Sorry, my question is  "Is it limited by hw performance"...
>>>
>>> I am much confused. why does this mmio mapping take a while?
>>> I guessed it takes a lot of time to set up p2m / iommu entry. That's
>>> why I ask "Is it limited by hw performance".
>>
>>Well, just count the number of page table entries and that of the resulting
>>hypercall continuations. It's the sheer amount of work that's causing the
>>slowness, together with the need for us to use continuations to be on the safe
>>side. There may well be redundant TLB invalidations as well. Since we can do
>>better (by using large
>>pages) I wouldn't call this "limited by hw performance", but of course one
>>may.
>>
> 
> I agree.
> So far as I know, xen upstream doesn't support to pass-through large bar 
> (pci-e bar > 4G) device, such as nvidia M60,
> However cloud providers may want to leverage this feature for machine 
> learning .etc.
> Is it on your TODO list?

Is what on my todo list? I was assuming large BAR handling to work
so far (Konrad had done some adjustments there quite a while ago,
from all I recall).

Jan

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

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

2017-03-20 Thread osstest service owner 
flight 106780 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106780/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-libvirt-xsm 3 host-install(3) broken in 106769 pass in 106780
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 3 host-install(3) broken 
pass in 106769

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 106755
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 106755
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 106755

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail in 106769 never pass
 build-arm64-xsm   5 xen-buildfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 build-arm64   5 xen-buildfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 build-arm64-pvops 5 kernel-build fail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  a6d681485ff85e27859583a5c20e1630c5cf8352
baseline version:
 libvirt  f0803dae93d62a4b8a2f67f4873c290a76d978b3

Last test of basis   106755  2017-03-18 04:21:23 Z2 days
Testing same since   106769  2017-03-19 04:20:15 Z1 days2 attempts


People who touched revisions under test:
  John Ferlan 

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



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

Logs, config files, etc. are available at

[Xen-devel] [PATCH v18] xen/sndif: Add sound-device ABI

2017-03-20 Thread Oleksandr Andrushchenko 
From: Oleksandr Andrushchenko 

Add ABI for the two halves of a para-virtualized
sound driver to communicate with each other.

The ABI allows implementing audio playback and capture as
well as volume control and possibility to mute/unmute
audio sources.

Note: depending on the use-case backend can expose more sound
cards and PCM devices/streams than the underlying HW physically
has by employing SW mixers, configuring virtual sound streams,
channels etc. Thus, allowing fine tunned configurations per
frontend.

Reviewed-by: Konrad Rzeszutek Wilk 
Signed-off-by: Oleksandr Andrushchenko 
Signed-off-by: Oleksandr Grytsov 
Signed-off-by: Oleksandr Dmytryshyn 
Signed-off-by: Iurii Konovalenko 

---
Changes since v1:
 * removed __attribute__((__packed__)) from all structures definitions

Changes since v2:
 * removed all C structures
 * added protocol description between frontend and backend drivers

Changes since v3:
 * fixed some typos
 * renamed XENSND_PCM_FORMAT_FLOAT_** to XENSND_PCM_FORMAT_F32_**
 * renamed XENSND_PCM_FORMAT_FLOAT64_** to XENSND_PCM_FORMAT_F64_**
 * added 'id' field to the request and response packets
 * renamed 'stream_id' to 'stream' in the packets description
 * renamed 'pcm_data_rate' to 'pcm_rate' in the packets description
 * renamed 'pcm_stream_type' to 'pcm_type' in the packets description
 * removed 'stream_id' field from the response packets

Changes since v4:
 * renamed 'stream_id' back to the to 'stream' in the packets description
 * moved 'id' field to the upper position in the response packets

Changes since v5:
 * Slightly reworked request/response packets
 * Size of the request/response packet is changed to the 64 bytes
 * Now parameters for the XENSND_OP_SET_VOLUME/XENSND_OP_GET_VOLUME are
   passed via shared page
 * Added parameters for the XenBus nodes (now each stream can be mapped
   to the defined sound device in the backend using those parameters)
 * Added XenBus state diagrams description

Changes since v6:
 * Reworked streams description  in the Backend XenBus Nodes

Changes since v7:
 * re-worked backend device parameters to be more generic and flexible
 * extended frontend device parameters
 * slightly updated state machine description added mute/unmute commands
 * added constants for XenStore configuration strings
   (fields, PCM formats etc.)
 * changed request/response structure size from 64 octets to 16
 * introduced dynamic buffer allocation instead of
   static XENSND_MAX_PAGES_PER_REQUEST
 * re-worked open request to allow dynamic buffer allocation
 * re-worked read/write/volume requests, so they don't pass grefs:
   buffer from the open request is used for these operations to pass data
 * specified type of the volume value to be a signed value in steps
   of 0.001 dBm, while 0 being 0dBm.
 * added Linux include file with structure definitions

Changes since v8:
 * changed frontend-id to frontend_id
 * single sound card support, configured with bunch of
   devices/streams
 * clarifucation made on sample rates and formats expressed as
   decimals w/o any particular ordering
 * put description of migration/disconnection state
 * replaced __attribute__((packed)) to __packed
 * changed padding of ring structures to 64 to fit cache line
 * removeed #ifdef __KERNEL
 * explicitly stated which indices in XenStore configuration
   are contiguous
 * added description to what frontend's defaults are
 * made names of virtual card/devices optional
 * removed PCM_FORMAT_SPECIAL
 * changed volume units from dBm to dB

Changes since v9:
 * removed sndif_linux.h
 * moved all structures from sndif_linux.h to sndif.h
 * structures padded where needed
 * fixed Hz comment

Changes since v10:
 * fixed tabs to 4 spaces to comply with Xen coding style
 * added placeholders to empty structures (C89 concern)
 * added missing header includes

Changes since v11:
 * added XENSND_RSP_NOTSUPP error code
 * changed gref[0] to gref[1] with comment
 * modified comments on empty structures
 * removed "__" from member names
 * fixed indentation
 * added padding in union xensnd_resp
 * changed __XEN_PUBLIC_IO_XENSND_H__ to __XEN_PUBLIC_IO_SNDIF_H__

Changes since v12:
 * changed indentation for defines
 * missed ";" after gref[1]
 * documentation changes
 * changed req/resp structures
 * changed xensnd_page_directory structure
 * pass buffer size in open request

Changes since v13:
 * note on usage of grant ref 0
 * all page sizes are XEN_PAGE_SIZE
 * padding/reserved cleanup/fixes
 * removed empty structures

Changes since v14:
 * turn padding into reserved

Changes since v15:
 * protocol description reworked
 * added offset to block notations
 * used -XEN_EXX for status reporting
 * added protocol versioning
 * removed stream_idx from the packet structure
 * changed xenstore paths

Changes since v16:

[Xen-devel] [PATCH v18] xen/sndif: Add sound-device ABI

2017-03-20 Thread Oleksandr Andrushchenko 
From: Oleksandr Andrushchenko 

Hi, all!

Please find the next version of the ABI for the PV sound
after addressing review comments.

Thank you,
Oleksandr Andrushchenko
Oleksandr Grytsov

Oleksandr Andrushchenko (1):
  xen/sndif: Add sound-device ABI

 xen/include/public/io/sndif.h | 803 ++
 1 file changed, 803 insertions(+)
 create mode 100644 xen/include/public/io/sndif.h

-- 
2.7.4


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

Re: [Xen-devel] [PATCH 08/18] xen/arm: Introduce a initcall to update cpu_hwcaps by serror_op

2017-03-20 Thread Wei Chen 
Hi Stefano,

On 2017/3/18 1:21, Stefano Stabellini wrote:
> On Fri, 17 Mar 2017, Wei Chen wrote:
>> Hi Stefano,
>> On 2017/3/17 7:30, Stefano Stabellini wrote:
>>> On Mon, 13 Mar 2017, Wei Chen wrote:
 In the later patches of this series, we want to use the alternative
 patching framework to avoid checking serror_op in every entries.
 So we define a new cpu feature "SKIP_CHECK_PENDING_VSERROR" for
 serror_op. When serror_op is not equal to SERROR_DIVERSE, this
 feature will be set to cpu_hwcaps.

 But we could not update cpu_hwcaps directly in the serror parameter
 parsing function. Because if the serror parameter is not placed in
 the command line, the parsing function would not be invoked.
>>>
>>> Wait, the only way to set serrors_op != SERRORS_DIVERSE is to pass the
>>> "serror" command line parameter. The parsing function is always invoked
>>> if serrors_op != SERRORS_DIVERSE.
>>>
>>
>> Yes, but that because we set serrors_op to SERRORS_DIVERSE by default.
>> If we change the policy and set serrors_op to SERRORS_PANIC by default,
>> then the parsing function would never be invoked.
>
> Ah, I see. It's not actually "to guarantee the cpu_hwcaps can be updated
> no matter the serror parameter is placed in the command line or not",
> because today it would always be the case.
>
> It's to future-proof the code, in case one day we'll change the default
> SERRORS behavior.
>

Yes, it's future-proof. I will update the commit message to be more
accurate.

>
>>>
 So, we introduce this initcall to guarantee the cpu_hwcaps can be
 updated no matter the serror parameter is placed in the command line
 or not.

 Signed-off-by: Wei Chen 
 ---
  xen/arch/arm/traps.c | 9 +
  xen/include/asm-arm/cpufeature.h | 3 ++-
  2 files changed, 11 insertions(+), 1 deletion(-)

 diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
 index 5e31699..053b7fc 100644
 --- a/xen/arch/arm/traps.c
 +++ b/xen/arch/arm/traps.c
 @@ -134,6 +134,15 @@ static void __init parse_serrors_behavior(const char 
 *str)
  }
  custom_param("serrors", parse_serrors_behavior);

 +static __init int update_serrors_cpu_caps(void)
>>>
>>> I think the coding style is "static int __init" ...
>>>
>>
>> Oh, thanks, I will fix it.
>>
>>>
 +{
 +if ( serrors_op != SERRORS_DIVERSE )
 +cpus_set_cap(SKIP_CHECK_PENDING_VSERROR);
 +
 +return 0;
 +}
 +__initcall(update_serrors_cpu_caps);
 +
  register_t get_default_hcr_flags(void)
  {
  return  (HCR_PTW|HCR_BSU_INNER|HCR_AMO|HCR_IMO|HCR_FMO|HCR_VM|
 diff --git a/xen/include/asm-arm/cpufeature.h 
 b/xen/include/asm-arm/cpufeature.h
 index c0a25ae..ec3f9e5 100644
 --- a/xen/include/asm-arm/cpufeature.h
 +++ b/xen/include/asm-arm/cpufeature.h
 @@ -40,8 +40,9 @@
  #define ARM32_WORKAROUND_766422 2
  #define ARM64_WORKAROUND_834220 3
  #define LIVEPATCH_FEATURE   4
 +#define SKIP_CHECK_PENDING_VSERROR 5

 -#define ARM_NCAPS   5
 +#define ARM_NCAPS   6

  #ifndef __ASSEMBLY__

 --
 2.7.4


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

>>>
>>
>>
>> --
>> Regards,
>> Wei Chen
>>
>> ___
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> https://lists.xen.org/xen-devel
>>
>


-- 
Regards,
Wei Chen

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

Re: [Xen-devel] [PATCH 1/2] xen/arm32: Introduce alternative runtime patching

2017-03-20 Thread Wei Chen 
Hi Konrad,

On 2017/3/17 22:34, Konrad Rzeszutek Wilk wrote:
> On Thu, Mar 16, 2017 at 05:53:38PM +0800, Wei Chen wrote:
>> This patch is based on the implementation of ARM64, it introduces
>> alternative runtime patching to ARM32. This allows to patch assembly
>> instruction at runtime to either fix hardware bugs or optimize for
>> certain hardware features on ARM32 platform.
>>
>> Xen hypervisor is using ARM execution state only on ARM32 platform,
>> Thumb is not used. So, the Thumb only branch instructions (CBZ, CBNZ,
>> TBB and TBH) are not considered in alternatives.
>>
>> The left ARM32 branch instructions are BX, BLX, BL and B. The
>> instruction BX is taking a register in parameter, so we don't need to
>> rewrite it. The instructions BLX, BL and B are using the similar
>> encoding for the offset and will avoid specific case when extracting
>> and updating the offset.
>>
>> In this patch, we include alternative.h header file to livepatch.c
>> directly for ARM32 compilation issues. When the alternative patching
>> config is enabled, the livepatch.c will use the alternative functions.
>> In this case, we should include the alternative header file to this
>> file. But for ARM64, it does not include this header file directly.
>> It includes this header file indirectly through:
>> sched.h->domain.h->page.h->alternative.h.
>> But, unfortunately, the page.h of ARM32 doesn't include alternative.h,
>> and we don't have the reason to include it to ARM32 page.h now. So we
>> have to include the alternative.h directly in livepatch.c.
>
> OK, thanks for the explanation.
>
>
> Could you also confirm that the test-cases for livepatching
> does compile for you?
>
> make -C xen tests
>
> should do it (specifically I am curious if xen_hello_world_func.c
> compiles fine).
>

Yes, the test-cases for livepatching can compile successfully.
I paste the full compiling log below:


arm32@P300:~/X32/Xen32$ make -C xen tests
make: Entering directory '/home/arm32/X32/Xen32/xen'
make -f Rules.mk _tests
make[1]: Entering directory '/home/arm32/X32/Xen32/xen'
make -f /home/arm32/X32/Xen32/xen/Rules.mk -C test tests
make[2]: Entering directory '/home/arm32/X32/Xen32/xen/test'
make -f /home/arm32/X32/Xen32/xen/Rules.mk -C livepatch livepatch
make[3]: Entering directory '/home/arm32/X32/Xen32/xen/test/livepatch'
arm-linux-gnueabihf-gcc -marm -DBUILD_ID -fno-strict-aliasing -std=gnu99 
-Wall -Wstrict-prototypes -Wdeclaration-after-statement 
-Wno-unused-but-set-variable -Wno-unused-local-typedefs   -O1 -nostdinc 
-fno-builtin -fno-common -Werror -Wredundant-decls -Wno-pointer-arith 
-pipe -g -D__XEN__ -include 
/home/arm32/X32/Xen32/xen/include/xen/config.h 
'-D__OBJECT_FILE__="xen_hello_world_func.o"' -Wa,--strip-local-absolute 
-fno-omit-frame-pointer -MMD -MF ./.xen_hello_world_func.o.d 
-msoft-float -mcpu=cortex-a15 -DCONFIG_EARLY_PRINTK 
-DEARLY_PRINTK_INC=\"debug-pl011.inc\" -DEARLY_PRINTK_BAUD= 
-DEARLY_UART_BASE_ADDRESS=0x1c09 -DEARLY_UART_REG_SHIFT= 
-I/home/arm32/X32/Xen32/xen/include -fno-stack-protector -fno-exceptions 
-Wnested-externs -DGCC_HAS_VISIBILITY_ATTRIBUTE -marm -DBUILD_ID 
-fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes 
-Wdeclaration-after-statement -Wno-unused-but-set-variable 
-Wno-unused-local-typedefs   -c xen_hello_world_func.c -o 
xen_hello_world_func.o
(set -e; \
  echo "#define NEW_CODE_SZ 0x0020"; \
  echo "#define MINOR_VERSION_SZ 0x0018"; \
  echo "#define MINOR_VERSION_ADDR 0x0023e580"; \
  echo "#define OLD_CODE_SZ 0x001c") > config.h
arm-linux-gnueabihf-gcc -marm -DBUILD_ID -fno-strict-aliasing -std=gnu99 
-Wall -Wstrict-prototypes -Wdeclaration-after-statement 
-Wno-unused-but-set-variable -Wno-unused-local-typedefs   -O1 -nostdinc 
-fno-builtin -fno-common -Werror -Wredundant-decls -Wno-pointer-arith 
-pipe -g -D__XEN__ -include 
/home/arm32/X32/Xen32/xen/include/xen/config.h 
'-D__OBJECT_FILE__="xen_hello_world.o"' -Wa,--strip-local-absolute 
-fno-omit-frame-pointer -MMD -MF ./.xen_hello_world.o.d -msoft-float 
-mcpu=cortex-a15 -DCONFIG_EARLY_PRINTK 
-DEARLY_PRINTK_INC=\"debug-pl011.inc\" -DEARLY_PRINTK_BAUD= 
-DEARLY_UART_BASE_ADDRESS=0x1c09 -DEARLY_UART_REG_SHIFT= 
-I/home/arm32/X32/Xen32/xen/include -fno-stack-protector -fno-exceptions 
-Wnested-externs -DGCC_HAS_VISIBILITY_ATTRIBUTE -marm -DBUILD_ID 
-fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes 
-Wdeclaration-after-statement -Wno-unused-but-set-variable 
-Wno-unused-local-typedefs   -c xen_hello_world.c -o xen_hello_world.o
arm-linux-gnueabihf-objcopy -O binary --only-section=.note.gnu.build-id 
/home/arm32/X32/Xen32/xen/xen-syms note.o.bin
arm-linux-gnueabihf-objcopy -I binary -O elf32-littlearm -B arm \
 
--rename-section=.data=.livepatch.depends,alloc,load,readonly,data,contents 
-S note.o.bin note.o
rm -f note.o.bin
arm-linux-gnueabihf-ld-EL -EL --build-id=sha1 -r -o 
xen_hello_world.livepatch xen_hello_world_func.o xen_hello_world.o note.o
arm-linux-gnueabihf-gcc -marm -DBUILD_ID

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

2017-03-20 Thread osstest service owner 
flight 106777 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106777/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-cubietruck 11 guest-start fail REGR. vs. 59254
 test-armhf-armhf-libvirt-xsm 11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-libvirt 11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-arndale  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-xsm  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-credit2  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-multivcpu 11 guest-start  fail REGR. vs. 59254

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemut-rhel6hvm-amd 3 host-install(3) broken in 106772 pass in 
106777
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 3 host-install(3) broken in 
106772 pass in 106777
 test-amd64-amd64-xl-credit2  3 host-install(3) broken in 106772 pass in 106777
 test-amd64-i386-xl-qemuu-winxpsp3 3 host-install(3) broken in 106772 pass in 
106777
 test-amd64-amd64-xl-xsm   3 host-install(3)  broken pass in 106766
 test-amd64-amd64-xl-qemuu-winxpsp3  3 host-install(3)broken pass in 106766
 test-amd64-i386-xl3 host-install(3)  broken pass in 106772
 test-amd64-i386-qemuu-rhel6hvm-amd  3 host-install(3)broken pass in 106772
 test-amd64-amd64-xl-pvh-intel 11 guest-start fail in 106766 pass in 106777
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 17 guest-start/win.repeat fail in 
106766 pass in 106777
 test-amd64-amd64-xl-qemut-win7-amd64 15 guest-localmigrate/x10 fail in 106772 
pass in 106777
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-saverestore.2 fail in 106772 
pass in 106777

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-rumprun-i386 3 host-install(3) broken in 106772 baseline 
untested
 test-armhf-armhf-xl-rtds 11 guest-start   fail REGR. vs. 59254
 test-amd64-amd64-xl-rtds  9 debian-installfail REGR. vs. 59254
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail 
baseline untested
 test-armhf-armhf-xl-vhd   9 debian-di-install   fail baseline untested
 test-armhf-armhf-libvirt-raw  9 debian-di-install   fail baseline untested
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail in 106766 like 59254
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 59254
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 59254
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 59254
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 59254

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail in 106772 never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 build-arm64-xsm   5 xen-buildfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 build-arm64   5 xen-buildfail   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-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass

version targeted for testing:
 linux93afaa4513bb08e69a3d6988ab4c3bf6c7cf07d3
baseline version:
 linux45820c294fe1b1a9df495d57f40585ef2d069a39

Last test of basis59254  2015-07-09 04:20:48 Z  620 days
Failing since 59348  2015-07-10 04:24:05 Z  619 days  346 attempts
Testing same since   106766  2017-03-19 02:11:19 Z1 days3 attempts


8084 people touched revisions under test,
not listing them all

jobs:
 build-amd64-xsm

<    1   2   3