[Xen-devel] [linux-4.1 bisection] complete test-amd64-i386-freebsd10-amd64

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-freebsd10-amd64
testid guest-start

Tree: linux 
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen git://xenbits.xen.org/xen.git
  Bug introduced:  c52319642bb9069436d4aec75361049f5fac63ed
  Bug not present: 268ead59ce10967cf7490353d743ebc1bb7a9a4c
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/95750/


  commit c52319642bb9069436d4aec75361049f5fac63ed
  Author: Andrew Cooper 
  Date:   Thu Jun 2 12:08:42 2016 +0100
  
  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 a valid action to take, but 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.
  As Xen doesn't yet support any XSS states in guests, unconditionally zero
  them.
  
  Reported-by: Luwei Kang 
  Signed-off-by: Andrew Cooper 
  Tested-by: Luwei Kang 
  Release-acked-by: Wei Liu 
  Reviewed-by: Jan Beulich 


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-4.1/test-amd64-i386-freebsd10-amd64.guest-start.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/linux-4.1/test-amd64-i386-freebsd10-amd64.guest-start
 --summary-out=tmp/95750.bisection-summary --basis-template=94729 
--blessings=real,real-bisect linux-4.1 test-amd64-i386-freebsd10-amd64 
guest-start
Searching for failure / basis pass:
 95591 fail [host=baroque1] / 94729 [host=elbling0] 94034 [host=huxelrebe1] 
93220 [host=fiano1] 93111 [host=chardonnay1] 92143 [host=huxelrebe0] 91350 
[host=merlot0] 91189 [host=baroque0] 91008 [host=merlot1] 90845 [host=rimava0] 
89382 [host=huxelrebe1] 89248 [host=pinot1] 88721 [host=fiano1] 88639 
[host=chardonnay1] 88510 [host=rimava1] 88390 [host=italia0] 88251 ok.
Failure / basis pass flights: 95591 / 88251
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: linux 
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 888172862fa78505c4e4674c205a06586443d83f 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
df553c056104e3dd8a2bd2e72539a57c4c085bae 
44a072f0de0d57c95c2212bbce0232b7b74f 
c2a17869d5dcd845d646bf4db122cad73596a2be
Basis pass 7f30737678023b5becaf0e2e012665f71b886a7d 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
21f6526d1da331611ac5fe12967549d1a04e149b 
316a862e5534249a6e6d876b4e203342d3fb870e 
a6f2cdb633bf519244a16674031b8034b581ba7f
Generating revisions with ./adhoc-revtuple-generator  
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git#7f30737678023b5becaf0e2e012665f71b886a7d-888172862fa78505c4e4674c205a06586443d83f
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://xenbits.xen.org/qemu-xen-traditional.git#21f6526d1da331611ac5fe12967549d1a04e149b-df553c056104e3dd8a2bd2e72539a57c4c085bae
 
git://xenbits.xen.org/qemu-xen.git#316a862e5534249a6e6d876b4e203342d3fb870e-44a072f0de0d57c95c2212bbce0232b7b74f
 
git://xenbits.xen.org/xen.git#a6f2cdb633bf519244a16674031b8034b581ba7f-c2a17869d5dcd845d646bf4db122cad73596a2be
Loaded 10941 nodes in revision graph
Searching 

Re: [Xen-devel] [Patch v11 1/3] IOMMU: add a timeout parameter for device IOTLB invalidation

[Xu, Quan]

On June 02, 2016 6:25 PM, Jan Beulich  wrote:
> >>> On 01.06.16 at 11:05,  wrote:
> > From: Quan Xu 
> > v11: Change the timeout parameter from 'vtd_qi_timeout' to
> > 'iommu_dev_iotlb_timeout', which is not only for VT-d device
> > IOTLB invalidation, but also for other IOMMU implementations.
> 
> This goes after the first --- separator.
> 

Got it. It should be:

---
v11:
   - ...
   - ...
---


> > --- a/docs/misc/xen-command-line.markdown
> > +++ b/docs/misc/xen-command-line.markdown
> > @@ -996,6 +996,15 @@ debug hypervisor only).
> >
> >  >> Enable IOMMU debugging code (implies `verbose`).
> >
> > +### iommu\_dev\_iotlb\_timeout
> > +> `= `
> > +
> > +> Default: `1`
> 
> So on v10 I had made clear that any timeout reduction from its current value
> is, for the ATS case, not acceptable, unless you have proof that this lower
> value will fit all past, present, and future devices. Otherwise we're risking 
> a
> regression here.
> 

I really misunderstood the 'current value', which should be about 
'DMAR_OPERATION_TIMEOUT MILLISECS(1000) ', instead of ' IOMMU_QI_TIMEOUT 
MILLISECS(1)' in my patch.
So the default is 1000.
 
> > --- a/xen/drivers/passthrough/vtd/qinval.c
> > +++ b/xen/drivers/passthrough/vtd/qinval.c
> > @@ -28,6 +28,8 @@
> >  #include "vtd.h"
> >  #include "extern.h"
> >
> > +#define IOMMU_QI_TIMEOUT MILLISECS(1)
> 
> May I suggest VTD_QI_TIMEOUT (but see also below)?
> 

Agreed. VTD_QI_TIMEOUT is a better one.

> > @@ -163,14 +165,21 @@ static int queue_invalidate_wait(struct iommu
> *iommu,
> >  /* Now we don't support interrupt method */
> >  if ( sw )
> >  {
> > +s_time_t timeout;
> > +
> >  /* In case all wait descriptor writes to same addr with same data 
> > */
> > -start_time = NOW();
> > +timeout = flush_dev_iotlb ?
> > +  (NOW() + iommu_dev_iotlb_timeout * MILLISECS(1)) :
> 
> MILLISECS(iommu_dev_iotlb_timeout)
> 
> > +  (NOW() + IOMMU_QI_TIMEOUT);
> 
> Or really the whole expression should probably simply become
> 
> timeout = NOW() + MILLISECS(flush_dev_iotlb ?
> iommu_dev_iotlb_timeout : VTD_QI_TIMEOUT);
> 
> (of course with VTD_QI_TIMEOUT having its MILLISECS() dropped, and
> suitably line wrapped).
> 


I prefer this later one.

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

Re: [Xen-devel] [PATCH v8 02/11] IOMMU/MMU: enhance the call trees of IOMMU unmapping and mapping

[Xu, Quan]

On June 14, 2016 12:37 AM,  George Dunlap  wrote:
> On Mon, Jun 13, 2016 at 4:17 PM, Xu, Quan  wrote:
> > From: Quan Xu 
> >
> > When IOMMU mapping is failed, we issue a best effort rollback,
> > stopping IOMMU mapping, unmapping the previous IOMMU maps and
> then
> > reporting the error up to the call trees. When rollback is not
> > feasible (in early initialization phase or trade-off of complexity)
> > for the hardware domain, we do things on a best effort basis, only throwing
> out an error message.
> >
> > IOMMU unmapping should perhaps continue despite an error, in an
> > attempt to do best effort cleanup.
> >
> > Signed-off-by: Quan Xu 
> > Reviewed-by: Jan Beulich 
> > Reviewed-by: Suravee Suthikulpanit 
> > Acked-by: Kevin Tian 
> 
> Acked-by: George Dunlap 
> 
> Phew!
> 
> One comment...
> 
> > +while ( i-- )
> > +/*
> > + * IOMMU unmapping should perhaps continue 
> > despite an
> > + * error in an attempt to do best effort 
> > cleanup, and
> > + * consume the error as __must_check 
> > annotation.
> > + */
> > +if ( iommu_unmap_page(p2m->domain, gfn + i) )
> > +continue;
> 
> I'd take out the "perhaps", (since there's no 'perhaps' about it) but other 
> than
> that I think this comment is fine.
> 
> It sounds like Jan had something more along the following in mind:
> 
> /* If statement to satisfy __must_check */
> 
> Either one works.  The shorter one is sufficient, but the longer one isn't too
> much I don't think.
> 
George,
Thanks for your comment.. I think your shorter one is better.

Jan, 
Could you help me review patch 7?   Thanks. 
Then, I can send out next v9 soon and get started to focus on next patch set.

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

[Xen-devel] [xen-unstable bisection] complete test-amd64-amd64-qemuu-nested-intel

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-qemuu-nested-intel
testid xen-boot/l1

Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen git://xenbits.xen.org/xen.git
  Bug introduced:  c52319642bb9069436d4aec75361049f5fac63ed
  Bug not present: 268ead59ce10967cf7490353d743ebc1bb7a9a4c
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/95743/


  commit c52319642bb9069436d4aec75361049f5fac63ed
  Author: Andrew Cooper 
  Date:   Thu Jun 2 12:08:42 2016 +0100
  
  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 a valid action to take, but 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.
  As Xen doesn't yet support any XSS states in guests, unconditionally zero
  them.
  
  Reported-by: Luwei Kang 
  Signed-off-by: Andrew Cooper 
  Tested-by: Luwei Kang 
  Release-acked-by: Wei Liu 
  Reviewed-by: Jan Beulich 


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable/test-amd64-amd64-qemuu-nested-intel.xen-boot--l1.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/xen-unstable/test-amd64-amd64-qemuu-nested-intel.xen-boot--l1
 --summary-out=tmp/95743.bisection-summary --basis-template=95353 
--blessings=real,real-bisect xen-unstable test-amd64-amd64-qemuu-nested-intel 
xen-boot/l1
Searching for failure / basis pass:
 95543 fail [host=godello1] / 95353 [host=italia1] 95309 [host=fiano1] 95281 
[host=fiano0] 95242 [host=baroque1] 95222 [host=huxelrebe1] 95203 
[host=huxelrebe0] 95174 [host=elbling0] 95129 [host=elbling1] 95086 
[host=baroque0] 94967 [host=chardonnay0] 94959 [host=chardonnay1] 94895 
[host=fiano1] 94876 [host=baroque1] 94852 [host=italia0] 94802 [host=fiano0] 
94789 [host=elbling0] 94780 [host=huxelrebe0] 94770 [host=elbling1] 94756 
[host=chardonnay0] 94746 [host=baroque1] 94740 [host=chardonnay1] 94730 
[host=baroque0] 94718 [host=huxelrebe1] 94699 [host=elbling0] 94639 
[host=italia0] 94616 [host=fiano1] 94610 [host=fiano0] 94580 [host=italia1] 
94536 [host=elbling1] 94507 [host=baroque1] 94495 [host=baroque0] 94487 
[host=huxelrebe1] 94461 [host=chardonnay1] 94442 [host=fiano1] 94070 
[host=chardonnay0] 94021 [host=fiano0] 93963 [host=baroque1] 93920 
[host=elbling1] 93873 [host=huxelrebe1] 93813 [host=baroque0] 93725 
[host=italia0] 93638 [host=italia1] 93612 [host=huxelrebe0] 93587 [host=fiano1] 
93563 [host=fiano0] 93515 [host=chardonnay1] 93496 [host=elbling0] 93408 
[host=baroque1] 93381 [host=elbling1] 93364 [host=italia1] 93337 
[host=huxelrebe0] 93296 [host=baroque0] 93272 [host=chardonnay0] 93256 
[host=fiano1] 93225 [host=fiano0] 93001 [host=huxelrebe1] 92925 [host=baroque0] 
92791 [host=elbling1] 92651 [host=italia0] 92543 [host=godello0] 92456 
[host=huxelrebe0] 92263 [host=chardonnay1] 92185 ok.
Failure / basis pass flights: 95543 / 92185
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest f06cb456a442c7df95a4ba6e2f3a341cf925d7cf 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
6e20809727261599e8527c456eb078c0e89139a1 

Re: [Xen-devel] Question of xl dump-core

[wj zhou]

Hi,

Thanks a lot for your reply!

On Tue, Jun 14, 2016 at 11:02 PM, Konrad Rzeszutek Wilk
 wrote:
> On Tue, Jun 14, 2016 at 08:21:16AM +0800, wj zhou wrote:
>> Hello all,
>
> Hey,
>
> CC-ing Daniel, and Dave.
>>
>> Sorry to disturb you, but I really want to figure it out.
>> The xen core of redhat 6 with pod is unable to be used with crash.
>>
>> I installed a hvm of redhat 6 by xen 4.7.0-rc2.
>> And the memory is set as below:
>> memory=1024
>> maxmem=4096
>>
>> "xl dump-core" is executed, and the core is produced successfully.
>> I got the following message:
>> xc: info: exceeded nr_pages (26) losing pages
>>
>> Unfortunately, I got some errors when executing crash with it.
>> The below is the log of crash.
>>
>> 
>> crash 7.0.9-4.el7
>
> http://people.redhat.com/anderson says that the latest is 7.1.5.
> Can you try that version?
>

I have just tried the latest crash version, and got the same error message.
Since the following info exists, I think there is something wrong in xen.
xc: info: exceeded nr_pages (26) losing pages

>> ...
>>
>> please wait... (gathering kmem slab cache data)
>> crash: read error: kernel virtual address: 88010b532e00  type:
>> "kmem_cache buffer"
>>
>> crash: unable to initialize kmem slab cache subsystem
>>
>> please wait... (gathering module symbol data)
>> crash: read error: physical address: 1058a1000  type: "page table"
>> 
>>
>> I knew balloon is not supported by redhat 6, so pod is also not supported.
>
> ?
>

In redhat 6 hvm, there is no balloon module.

>> But I wonder the reason why the above error happens.
>> Balloon and pod are also not supported by redhat 7, but it won't
>> happen in redhat 7 hvm.
>> I'm very appreciated if someone can help me.
>
> Well, does it work if you maxmem != memory ?
>

Yes, it works in redhat 7 hvm when maxmem>memory.

But I found something strange.
"free -m" performs quite different between redhat6 and redhat7 hvm.
In redhat 6 the value by "free -m" equals maxmem(4096).
However, in redhat 7 it equals memory(1024),

-- 
Regards
Zhou

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

Re: [Xen-devel] [PATCH] xen/arm: map_dev_mmio_region: The iomem permission check should be done on MFN

[Shannon Zhao]

Hi Julien,

On 2016/6/14 19:50, Julien Grall wrote:
> The helper iomem_access_permitted expects MFNs in parameters and not
> GNFs. Thankfully only the hardware domain can call this function and
> it will always be with GFNS == MFNs for now.
> 
> Also, fix the printf to use the MFN range and not the GFN one.
> 
> Signed-off-by: Julien Grall 
> Cc: Shannon Zhao 
> 
Reviewed-by: Shannon Zhao 

> ---
> This patch is a good candidate to backport to Xen 4.7. Without
> it, the hardware domain can map any MMIO because the permission
> check is done on the GPFNs and not the MNFs.
> ---
>  xen/arch/arm/p2m.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index 6a19c57..4c6547d 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -1275,14 +1275,14 @@ int map_dev_mmio_region(struct domain *d,
>  {
>  int res;
>  
> -if ( !(nr && iomem_access_permitted(d, start_gfn, start_gfn + nr - 1)) )
> +if ( !(nr && iomem_access_permitted(d, mfn, mfn + nr - 1)) )
>  return 0;
>  
>  res = map_mmio_regions(d, start_gfn, nr, mfn);
>  if ( res < 0 )
>  {
>  printk(XENLOG_G_ERR "Unable to map [%#lx - %#lx] in Dom%d\n",
> -   start_gfn, start_gfn + nr - 1, d->domain_id);
> +   mfn, mfn + nr - 1, d->domain_id);
>  return res;
>  }
>  
> 

-- 
Shannon


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

Re: [Xen-devel] [PATCH v8 09/11] vt-d: fix the IOMMU flush issue

[Tian, Kevin]

> From: Xu, Quan
> Sent: Tuesday, June 14, 2016 5:04 PM
> 
> On June 14, 2016 4:27 PM, Jan Beulich  wrote:
> > >>> On 14.06.16 at 10:10,  wrote:
> > > On June 13, 2016 11:52 PM, Jan Beulich  wrote:
> > >> >>> "Xu, Quan"  06/13/16 5:22 PM >>>
> > >> >From: Quan Xu 
> > >> >@@ -546,17 +550,37 @@ static int __must_check iommu_flush_all(void)
> > >> >struct acpi_drhd_unit *drhd; struct iommu *iommu; int
> > >> >flush_dev_iotlb;
> > >> >+int rc = 0;
> > >>  >
> > >> >flush_all_cache();
> > >> >for_each_drhd_unit ( drhd )
> > >> >{
> > >> >+int iommu_rc, iommu_ret;
> > >> >+
> > >> >iommu = drhd->iommu;
> > >> >-iommu_flush_context_global(iommu, 0);
> > >> >+iommu_rc = iommu_flush_context_global(iommu, 0);
> > >> >flush_dev_iotlb = find_ats_dev_drhd(iommu) ? 1 : 0;
> > >> >-iommu_flush_iotlb_global(iommu, 0, flush_dev_iotlb);
> > >> >+iommu_ret = iommu_flush_iotlb_global(iommu, 0,
> > >> >+ flush_dev_iotlb);
> > >> >+
> > >> >+/*
> > >> >+ * The current logic for returns:
> > >> >+ *   - positive  invoke iommu_flush_write_buffer to flush 
> > >> >cache.
> > >> >+ *   - zero  on success.
> > >> >+ *   - negative  on failure. Continue to flush IOMMU IOTLB on a
> > >> >+ *   best effort basis.
> > >> >+ */
> > >> >+if ( iommu_rc > 0 || iommu_ret > 0 )
> > >> >+iommu_flush_write_buffer(iommu);
> > >> >+if ( rc >= 0 )
> > >> >+rc = iommu_rc;
> > >> >+if ( rc >= 0 )
> > >> >+rc = iommu_ret;
> > >>
> > >> First of all - is it correct to fold the two
> > >> iommu_flush_write_buffer() invocations?
> > >>
> > >
> > > Sure, it is correct..
> > >
> > > as:
> > > - For updates to remapping hardware structures that require
> > > context-cache, PASID-cache, IOTLB or IEC invalidation Operations to
> > > flush stale entries from the hardware caches, no additional action is
> > > required to make the modification Visible to hardware. This is
> > > because, hardware performs an implicit write-buffer-flushing as a
> > > pre-condition to context-cache, PASID-cache, IOTLB and IEC
> > > invalidation operations.
> > >
> > > - For updates to remapping hardware structures (such as modifying a
> > > currently not-present entry) that do not require Context-cache, IOTLB,
> > > or IEC invalidations, software must explicitly perform
> > > write-buffer-flushing to ensure the updated structures Are visible to
> > > hardware.
> >
> > But that's not the point. Instead my question was related to Kevin's concern
> > towards you making assumptions on the behavior of
> > iommu_flush_context_global() vs iommu_flush_iotlb_global(): What if the
> > first returned 1 but the second didn't?
> > It would seem to me that in such a
> > (theoretical) case iommu_flush_write_buffer() might need to be invoked prior
> > to the second flush function.
> 
> In this case, it is correct too.
> As , hardware performs an __implicit__ write-buffer-flushing as a 
> __pre-condition__ to
> IOTLB invalidation operation.
> So software is no need to call iommu_flush_write_buffer() to explicitly 
> perform
> write-buffer-flushing for that the first returned 1.
> 

Yes, there is no issue doing so based on spec.

Thanks
Kevin

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

[Xen-devel] [linux-3.10 test] 95665: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-win7-amd64  3 host-install(3)  broken REGR. vs. 86412
 test-amd64-amd64-xl-multivcpu  3 host-install(3)broken REGR. vs. 86412
 test-amd64-i386-qemut-rhel6hvm-amd  3 host-install(3)   broken REGR. vs. 86412
 test-amd64-i386-xl-raw3 host-install(3) broken REGR. vs. 86412
 test-amd64-amd64-xl-qemuu-winxpsp3  3 host-install(3)   broken REGR. vs. 86412
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 3 host-install(3) broken 
REGR. vs. 86412
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 3 host-install(3) broken REGR. 
vs. 86412
 test-amd64-amd64-pair3 host-install/src_host(3) broken REGR. vs. 86412
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1fail REGR. vs. 86412
 test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1  fail REGR. vs. 86412

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-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-libvirt 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-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass

version targeted for testing:
 linuxca1199fccf14540e86f6da955333e31d6fec5f3e
baseline version:
 linux326a1b2d50cbe1f890e56ab60b9215cd30053f5a

Last test of basis86412  2016-03-16 16:24:33 Z   90 days
Testing same since95665  2016-06-13 14:51:45 Z1 days1 attempts


People who touched revisions under test:
  Aaro Koskinen 
  Adrian Hunter 
  Al Viro 
  Alan Stern 
  Alex Deucher 
  Alexandre Belloni 
  Alexandre Bounine 
  Alexey Khoroshilov 
  Allain Legacy 
  Andi Kleen 
  Andrew Morton 
  Andrey Gelman 
  Andy Lutomirski 
  Andy Lutomirski  # On a Dell XPS 13 9350
  Anton Blanchard 
  Antonio Quartulli 
  Aristeu Rozanski 
  Arnaldo Carvalho de Melo 
  Arnd Bergmann 
  Artem Bityutskiy 
  Aurelien Jacquiot 
  Behan Webster 
  Ben Hutchings 
  Bill Sommerfeld 
  Bjorn Helgaas 
  Bjørn Mork 
  Bob Moore 
  Borislav Petkov 
  Brian King 
  Brian Norris 
  Chanwoo Choi 
  Chas Williams <3ch...@gmail.com>
  Chris Friesen 
  Dan Carpenter 
  Dan Streetman 
  Daniel Fraga 
  Daniel Lezcano 
  David S. Miller 
  Diego Viola 
  Dinh Nguyen 
  Dmitry Ivanov 
  Dmitry Ivanov 
  Dmitry Torokhov 
  Douglas Gilbert 
  Eric Wheeler 
  Eric Wheeler 
  Eryu Guan 
  Felipe Balbi 
  Florian Westphal 
  Gabriel Krisman Bertazi 
  Geert Uytterhoeven 
  Greg 

[Xen-devel] [PATCH v2 1/1] tools/livepatch: cleanup unnecessary "j = ARRAY_SIZE(action_options); "

[Dongli Zhang]

Local variable "j" would be used only when "i == ARRAY_SIZE(main_options)"
is true. Thus, it is not necessary to update "j" when "i ==
ARRAY_SIZE(main_options)" is false.

Signed-off-by: Dongli Zhang 
---
 tools/misc/xen-livepatch.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/tools/misc/xen-livepatch.c b/tools/misc/xen-livepatch.c
index 28f339a..62c072e 100644
--- a/tools/misc/xen-livepatch.c
+++ b/tools/misc/xen-livepatch.c
@@ -412,7 +412,7 @@ struct {
 
 int main(int argc, char *argv[])
 {
-int i, j, ret;
+int i, j = 0, ret;
 
 if ( argc  <= 1 )
 {
@@ -435,8 +435,7 @@ int main(int argc, char *argv[])
"'xen-livepatch help'\n", argv[1]);
 return 1;
 }
-} else
-j = ARRAY_SIZE(action_options);
+}
 
 xch = xc_interface_open(0,0,0);
 if ( !xch )
-- 
1.9.1


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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1fail REGR. vs. 95164
 test-amd64-i386-freebsd10-amd64 10 guest-startfail REGR. vs. 95164
 test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1 fail in 95585 REGR. vs. 95164

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-amd64-pvgrub  3 host-install(3) broken in 95585 pass in 95657
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 3 host-install(3) broken pass in 
95585
 test-amd64-amd64-qemuu-nested-amd  3 host-install(3)  broken pass in 95585
 test-amd64-i386-libvirt   3 host-install(3)   broken pass in 95585
 test-amd64-amd64-xl-qemuu-ovmf-amd64  3 host-install(3)   broken pass in 95585
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 3 host-install(3) broken pass in 
95585
 test-amd64-amd64-xl-xsm   3 host-install(3)   broken pass in 95585
 test-amd64-i386-xl-qemuu-winxpsp3  3 host-install(3)  broken pass in 95585
 test-amd64-i386-xl-qemut-winxpsp3  3 host-install(3)  broken pass in 95585

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

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-i386-libvirt  12 migrate-support-check fail in 95585 never pass
 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-amd64-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-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

version targeted for testing:
 linux022aafd04696a3c6b7ad47ab83a9650646287bf8
baseline version:
 linuxf06cb456a442c7df95a4ba6e2f3a341cf925d7cf

Last test of basis95164  2016-06-01 19:46:34 Z   13 days
Testing same since95407  2016-06-08 00:46:14 Z6 days5 attempts


People who touched revisions under test:
  Andrew Morton 
  Ben Hutchings 
  Bjorn Helgaas 
  Daniel Lezcano 
  Daniel Vetter 
  Dave Chinner 
  Dave Chinner 
  Dave Gerlach 
  David Vrabel 
  Dmitry Torokhov 
  Greg Kroah-Hartman 
  Hari Bathini 
  Itai Handler 
  J. Bruce Fields 
  James Hogan 
  Jeff Layton 
  Joseph Salisbury 
  Kalle Valo 
  Kalle Valo 
  Larry Finger 
  Linus Torvalds 
  Lyude 
  Mahesh Salgaonkar 
  Martin K. Petersen 
  Matthias Schiffer 
  Michael Ellerman 
  Nicolai Stange 
  Patrik Jakobsson 
  Paul Burton 
  Prarit Bhargava 
  Rafael J. Wysocki 
  Raghava Aditya Renukunta 
  Ralf Baechle 
  Ricky Liang 
  Ross Lagerwall 
  Shyam Kaushik 
  Theodore Ts'o 
  Tomáš Trnka 
  Ville Syrjälä 
  Wang YanQing 

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

[Xen-devel] Xen-unstable 4.8: HVM domain_crash called from emulate.c:144 RIP: c000:[<000000000000336a>]

[linux]

Hi,

Just tested latest xen-unstable 4.8 (xen_changeset git:d337764),
but one of the latest commits seems to have broken boot of HVM guests
(using qemu-xen) previous build with xen_changeset git:6e908ee worked 
fine.


--
Sander

(XEN) [2016-06-14 22:47:36.827] HVM19 save: CPU
(XEN) [2016-06-14 22:47:36.827] HVM19 save: PIC
(XEN) [2016-06-14 22:47:36.827] HVM19 save: IOAPIC
(XEN) [2016-06-14 22:47:36.827] HVM19 save: LAPIC
(XEN) [2016-06-14 22:47:36.827] HVM19 save: LAPIC_REGS
(XEN) [2016-06-14 22:47:36.827] HVM19 save: PCI_IRQ
(XEN) [2016-06-14 22:47:36.827] HVM19 save: ISA_IRQ
(XEN) [2016-06-14 22:47:36.827] HVM19 save: PCI_LINK
(XEN) [2016-06-14 22:47:36.827] HVM19 save: PIT
(XEN) [2016-06-14 22:47:36.827] HVM19 save: RTC
(XEN) [2016-06-14 22:47:36.827] HVM19 save: HPET
(XEN) [2016-06-14 22:47:36.827] HVM19 save: PMTIMER
(XEN) [2016-06-14 22:47:36.827] HVM19 save: MTRR
(XEN) [2016-06-14 22:47:36.827] HVM19 save: VIRIDIAN_DOMAIN
(XEN) [2016-06-14 22:47:36.827] HVM19 save: CPU_XSAVE
(XEN) [2016-06-14 22:47:36.827] HVM19 save: VIRIDIAN_VCPU
(XEN) [2016-06-14 22:47:36.827] HVM19 save: VMCE_VCPU
(XEN) [2016-06-14 22:47:36.827] HVM19 save: TSC_ADJUST
(XEN) [2016-06-14 22:47:36.827] HVM19 restore: CPU 0
(d19) [2016-06-14 22:47:38.102] HVM Loader
(d19) [2016-06-14 22:47:38.102] Detected Xen v4.8-unstable
(d19) [2016-06-14 22:47:38.102] Xenbus rings @0xfeffc000, event channel 
1

(d19) [2016-06-14 22:47:38.102] System requested SeaBIOS
(d19) [2016-06-14 22:47:38.102] CPU speed is 3200 MHz
(d19) [2016-06-14 22:47:38.102] Relocating guest memory for lowmem MMIO 
space disabled
(XEN) [2016-06-14 22:47:38.102] irq.c:275: Dom19 PCI link 0 changed 0 -> 
5

(d19) [2016-06-14 22:47:38.103] PCI-ISA link 0 routed to IRQ5
(XEN) [2016-06-14 22:47:38.103] irq.c:275: Dom19 PCI link 1 changed 0 -> 
10

(d19) [2016-06-14 22:47:38.103] PCI-ISA link 1 routed to IRQ10
(XEN) [2016-06-14 22:47:38.103] irq.c:275: Dom19 PCI link 2 changed 0 -> 
11

(d19) [2016-06-14 22:47:38.103] PCI-ISA link 2 routed to IRQ11
(XEN) [2016-06-14 22:47:38.103] irq.c:275: Dom19 PCI link 3 changed 0 -> 
5

(d19) [2016-06-14 22:47:38.103] PCI-ISA link 3 routed to IRQ5
(d19) [2016-06-14 22:47:38.110] pci dev 01:3 INTA->IRQ10
(d19) [2016-06-14 22:47:38.112] pci dev 02:0 INTA->IRQ11
(d19) [2016-06-14 22:47:38.116] pci dev 04:0 INTA->IRQ5
(d19) [2016-06-14 22:47:38.127] No RAM in high memory; setting high_mem 
resource base to 1
(d19) [2016-06-14 22:47:38.127] pci dev 03:0 bar 10 size 00200: 
0f008
(d19) [2016-06-14 22:47:38.128] pci dev 02:0 bar 14 size 00100: 
0f208
(d19) [2016-06-14 22:47:38.128] pci dev 04:0 bar 30 size 4: 
0f300
(d19) [2016-06-14 22:47:38.129] pci dev 04:0 bar 10 size 2: 
0f304
(d19) [2016-06-14 22:47:38.129] pci dev 03:0 bar 30 size 1: 
0f306
(d19) [2016-06-14 22:47:38.130] pci dev 03:0 bar 14 size 01000: 
0f307
(d19) [2016-06-14 22:47:38.130] pci dev 02:0 bar 10 size 00100: 
0c001
(d19) [2016-06-14 22:47:38.131] pci dev 04:0 bar 14 size 00040: 
0c101
(d19) [2016-06-14 22:47:38.132] pci dev 01:1 bar 20 size 00010: 
0c141

(d19) [2016-06-14 22:47:38.132] Multiprocessor initialisation:
(d19) [2016-06-14 22:47:38.132]  - CPU0 ... 48-bit phys ... fixed MTRRs 
... var MTRRs [1/8] ... done.
(d19) [2016-06-14 22:47:38.132]  - CPU1 ... 48-bit phys ... fixed MTRRs 
... var MTRRs [1/8] ... done.
(d19) [2016-06-14 22:47:38.133]  - CPU2 ... 48-bit phys ... fixed MTRRs 
... var MTRRs [1/8] ... done.
(d19) [2016-06-14 22:47:38.133]  - CPU3 ... 48-bit phys ... fixed MTRRs 
... var MTRRs [1/8] ... done.

(d19) [2016-06-14 22:47:38.133] Writing SMBIOS tables ...
(d19) [2016-06-14 22:47:38.134] Loading SeaBIOS ...
(d19) [2016-06-14 22:47:38.134] Creating MP tables ...
(d19) [2016-06-14 22:47:38.134] Loading ACPI ...
(d19) [2016-06-14 22:47:38.135] vm86 TSS at fc00a200
(d19) [2016-06-14 22:47:38.135] BIOS map:
(d19) [2016-06-14 22:47:38.135]  1-100e3: Scratch space
(d19) [2016-06-14 22:47:38.135]  c-f: Main BIOS
(d19) [2016-06-14 22:47:38.135] E820 table:
(d19) [2016-06-14 22:47:38.135]  [00]: : - 
:000a: RAM
(d19) [2016-06-14 22:47:38.135]  HOLE: :000a - 
:000c
(d19) [2016-06-14 22:47:38.135]  [01]: :000c - 
:0010: RESERVED
(d19) [2016-06-14 22:47:38.135]  [02]: :0010 - 
:1f80: RAM
(d19) [2016-06-14 22:47:38.135]  HOLE: :1f80 - 
:fc00
(d19) [2016-06-14 22:47:38.135]  [03]: :fc00 - 
0001:: RESERVED

(d19) [2016-06-14 22:47:38.136] Invoking SeaBIOS ...
(d19) [2016-06-14 22:47:38.137] SeaBIOS (version rel-1.9.2-0-gd2aeb7f)
(d19) [2016-06-14 22:47:38.137] BUILD: gcc: (Debian 4.9.2-10) 4.9.2 
binutils: (GNU Binutils for Debian) 2.25

(d19) [2016-06-14 22:47:38.137]
(d19) [2016-06-14 22:47:38.137] Found Xen hypervisor signature at 
4000

(d19) [2016-06-14 22:47:38.138] Running on QEMU (i440fx)
(d19) 

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

[osstest service owner]

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

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  d337764d9b8e89eb9cb9d5be509823d9286f00c4
baseline version:
 xen  9b394b7eff681fc1b4c88d9dec88ed38ebf8c456

Last test of basis95732  2016-06-14 17:09:50 Z0 days
Testing same since95735  2016-06-14 19:01:08 Z0 days1 attempts


People who touched revisions under test:
  Ian Jackson 
  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=d337764d9b8e89eb9cb9d5be509823d9286f00c4
+ . ./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 
d337764d9b8e89eb9cb9d5be509823d9286f00c4
+ branch=xen-unstable-smoke
+ revision=d337764d9b8e89eb9cb9d5be509823d9286f00c4
+ . ./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.7-testing
+ '[' xd337764d9b8e89eb9cb9d5be509823d9286f00c4 = 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/
+++ '[' 

[Xen-devel] [xen-unstable test] 95654: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1fail REGR. vs. 95353

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-xsm3 host-install(3)   broken pass in 95543
 test-amd64-amd64-xl-qcow2 3 host-install(3)   broken pass in 95543
 test-amd64-amd64-amd64-pvgrub  3 host-install(3)  broken pass in 95543
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 3 host-install(3) broken pass in 
95543
 test-amd64-i386-pair  3 host-install/src_host(3)  broken pass in 95543
 test-amd64-i386-qemuu-rhel6hvm-amd  3 host-install(3) broken pass in 95543
 test-amd64-amd64-xl-qemuu-ovmf-amd64  3 host-install(3)   broken pass in 95543
 test-armhf-armhf-libvirt-raw  6 xen-boot   fail in 95543 pass in 95654
 test-armhf-armhf-xl-xsm   6 xen-boot   fail in 95543 pass in 95654
 test-armhf-armhf-xl-rtds 11 guest-startfail in 95543 pass in 95654
 test-armhf-armhf-xl-arndale 15 guest-start/debian.repeat fail in 95543 pass in 
95654

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-i386-rumpuserxen-i386  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-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   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-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   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 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-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail 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  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-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-amd64-amd64-libvirt-vhd 11 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
 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-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 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

version targeted for testing:
 xen  6e908ee108caec78f95e639b8ef43ac5dd1d5e45
baseline version:
 

Re: [Xen-devel] [PATCH 14/17] ocaml/libxs: generate a paths.ml

[David Scott]

> On 14 Jun 2016, at 10:36, Wei Liu  wrote:
> 
> On Mon, Jun 13, 2016 at 08:50:02PM +0100, David Scott wrote:
>> 
>>> On 13 Jun 2016, at 16:22, Wei Liu  wrote:
>>> 
>>> On Mon, Jun 13, 2016 at 04:19:59PM +0100, Ian Jackson wrote:
 Wei Liu writes ("[PATCH 14/17] ocaml/libxs: generate a paths.ml"):
> Signed-off-by: Wei Liu 
 
 FAOD I don't consider myself qualified to review this.
 
>>> 
>>> David gave his ack to a similar path so I presume he will be fine with
>>> this, too.
>>> 
>>> I will wait for his ack anyway.
>> 
>> Looks fine to me.
>> 
>> Acked-by: David Scott 
>> 
> 
> Thanks.
> 
> FAOD: I think this ack is only for this patch. I will hold off pushing
> this one and wait until other ocaml patches are asked.

I think I’ve acked the rest — let me know if I missed one :)

Cheers,
Dave

> 
> Wei.
> 
>> Cheers,
>> Dave
> 


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

Re: [Xen-devel] [PATCH 1/1] tools/livepatch: cleanup unnecessary "j = ARRAY_SIZE(action_options); "

[Konrad Rzeszutek Wilk]

On Tue, Jun 14, 2016 at 09:22:45PM +0200, Olaf Hering wrote:
> On Fri, Jun 10, Dongli Zhang wrote:
> 
> > Local variable "j" would be used only when "i == ARRAY_SIZE(main_options)"
> > is true. Thus, it is not necessary to update "j" when "i ==
> > ARRAY_SIZE(main_options)" is false.
> 
> This breaks the build with gcc45:
> 
> [  153s] cc1: warnings being treated as errors
> [  153s] xen-livepatch.c: In function 'main':
> [  153s] xen-livepatch.c:415:12: error: 'j' may be used uninitialized in this 
> function
> [  153s] make[3]: *** [xen-livepatch.o] Error 1
> 
> Olaf

?

diff --git a/tools/misc/xen-livepatch.c b/tools/misc/xen-livepatch.c
index 3162489..62c072e 100644
--- a/tools/misc/xen-livepatch.c
+++ b/tools/misc/xen-livepatch.c
@@ -412,7 +412,7 @@ struct {
 
 int main(int argc, char *argv[])
 {
-int i, j, ret;
+int i, j = 0, ret;
 
 if ( argc  <= 1 )
 {

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

Re: [Xen-devel] [PATCH 17/17] oxenstored: honour XEN_RUN_STORED in systemd C stub

[David Scott]

> On 13 Jun 2016, at 08:49, Wei Liu  wrote:
> 
> Generate a _paths.h for that and add proper dependency.
> 
> Signed-off-by: Wei Liu 
> ---
> Cc: Ian Jackson 
> Cc: David Scott 
> ---
> .gitignore| 1 +
> tools/ocaml/xenstored/Makefile| 7 +++
> tools/ocaml/xenstored/systemd_stubs.c | 6 --
> 3 files changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/.gitignore b/.gitignore
> index 5914bbe..e019f2e 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -349,6 +349,7 @@ tools/ocaml/libs/xentoollog/_xtl_levels.*
> tools/ocaml/libs/xentoollog/xentoollog.ml
> tools/ocaml/libs/xentoollog/xentoollog.mli
> tools/ocaml/libs/xs/paths.ml
> +tools/ocaml/xenstored/_paths.h
> tools/ocaml/xenstored/oxenstored
> tools/ocaml/xenstored/oxenstored.conf
> tools/ocaml/xenstored/paths.ml
> diff --git a/tools/ocaml/xenstored/Makefile b/tools/ocaml/xenstored/Makefile
> index 939dcaa..1769e55 100644
> --- a/tools/ocaml/xenstored/Makefile
> +++ b/tools/ocaml/xenstored/Makefile
> @@ -30,6 +30,8 @@ systemd_OBJS = systemd
> systemd_C_OBJS = systemd_stubs
> OCAML_LIBRARY += systemd
> 
> +$(foreach obj,$(systemd_C_OBJS),$(obj).o): _paths.h
> +
> LIBS_systemd += $(LDFLAGS-y)
> 
> OBJS = paths \
> @@ -93,3 +95,8 @@ genpath-target = $(call buildmakevars2module,paths.ml)
> $(eval $(genpath-target))
> 
> GENERATED_FILES += paths.ml
> +
> +genpath-target = $(call buildmakevars2header,_paths.h)
> +$(eval $(genpath-target))
> +
> +GENERATE_FILES += _paths.h
> diff --git a/tools/ocaml/xenstored/systemd_stubs.c 
> b/tools/ocaml/xenstored/systemd_stubs.c
> index a78a72b..322f1e0 100644
> --- a/tools/ocaml/xenstored/systemd_stubs.c
> +++ b/tools/ocaml/xenstored/systemd_stubs.c
> @@ -28,6 +28,8 @@
> #include 
> #include 
> 
> +#include "_paths.h"
> +
> /* Will work regardless of the order systemd gives them to us */
> static int oxen_get_sd_fd(const char *connect_to)
> {
> @@ -46,8 +48,8 @@ static int oxen_get_sd_fd(const char *connect_to)
> 
> static int oxen_verify_socket_socket(const char *connect_to)
> {
> - if ((strcmp("/var/run/xenstored/socket_ro", connect_to) != 0) &&
> - (strcmp("/var/run/xenstored/socket", connect_to) != 0)) {
> + if ((strcmp(XEN_RUN_STORED "/socket_ro", connect_to) != 0) &&
> + (strcmp(XEN_RUN_STORED "/socket", connect_to) != 0)) {
>   sd_notifyf(0, "STATUS=unexpected socket: %s\n"
>  "ERRNO=%i",
>  connect_to,
> -- 
> 2.1.4
> 


This also looks fine to me

Acked-by: David Scott 


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

Re: [Xen-devel] [PATCH 16/17] oxenstored: honour XEN_RUN_STORED and XEN_CONFIG_DIR

[David Scott]

> On 13 Jun 2016, at 08:49, Wei Liu  wrote:
> 
> Only contain changes to ocaml source code. C stub files will be handled
> separately.
> 
> Signed-off-by: Wei Liu 
> ---
> Cc: Ian Jackson 
> Cc: David Scott 
> ---
> tools/ocaml/xenstored/define.ml| 6 +++---
> tools/ocaml/xenstored/disk.ml  | 2 +-
> tools/ocaml/xenstored/xenstored.ml | 8 
> 3 files changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/tools/ocaml/xenstored/define.ml b/tools/ocaml/xenstored/define.ml
> index d60861c..e9d957f 100644
> --- a/tools/ocaml/xenstored/define.ml
> +++ b/tools/ocaml/xenstored/define.ml
> @@ -20,10 +20,10 @@ let xenstored_minor = 0
> let xenstored_proc_kva = "/proc/xen/xsd_kva"
> let xenstored_proc_port = "/proc/xen/xsd_port"
> 
> -let xs_daemon_socket = "/var/run/xenstored/socket"
> -let xs_daemon_socket_ro = "/var/run/xenstored/socket_ro"
> +let xs_daemon_socket = Paths.xen_run_stored ^ "/socket"
> +let xs_daemon_socket_ro = Paths.xen_run_stored ^ "/socket_ro"
> 
> -let default_config_dir = "/etc/xen"
> +let default_config_dir = Paths.xen_config_dir
> 
> let maxwatch = ref (50)
> let maxtransaction = ref (20)
> diff --git a/tools/ocaml/xenstored/disk.ml b/tools/ocaml/xenstored/disk.ml
> index 4ae1fce..4739967 100644
> --- a/tools/ocaml/xenstored/disk.ml
> +++ b/tools/ocaml/xenstored/disk.ml
> @@ -15,7 +15,7 @@
>  *)
> 
> let enable = ref false
> -let xs_daemon_database = "/var/run/xenstored/db"
> +let xs_daemon_database = Paths.xen_run_stored ^ "/db"
> 
> let error fmt = Logging.error "disk" fmt
> 
> diff --git a/tools/ocaml/xenstored/xenstored.ml 
> b/tools/ocaml/xenstored/xenstored.ml
> index fc8cc95..30570ed 100644
> --- a/tools/ocaml/xenstored/xenstored.ml
> +++ b/tools/ocaml/xenstored/xenstored.ml
> @@ -66,7 +66,7 @@ let process_domains store cons domains =
> let sigusr1_handler store =
>   try
>   let channel = open_out_gen [ Open_wronly; Open_creat; 
> Open_trunc; ]
> -0o600 "/var/run/xenstored/db.debug" 
> in
> +0o600 (Paths.xen_run_stored ^ 
> "/db.debug") in
>   finally (fun () -> Store.dump store channel)
>   (fun () -> close_out channel)
>   with _ ->
> @@ -266,7 +266,7 @@ let _ =
>   let quit = ref false in
> 
>   if cf.restart then (
> - DB.from_file store domains cons "/var/run/xenstored/db";
> + DB.from_file store domains cons (Paths.xen_run_stored ^ "/db");
>   Event.bind_dom_exc_virq eventchn
>   ) else (
>   if !Disk.enable then (
> @@ -293,7 +293,7 @@ let _ =
> 
>   Logging.init_xenstored_log();
>   if cf.activate_access_log then begin
> - let post_rotate () = DB.to_file store cons 
> "/var/run/xenstored/db" in
> + let post_rotate () = DB.to_file store cons 
> (Paths.xen_run_stored ^ "/db") in
>   Logging.init_access_log post_rotate
>   end;
> 
> @@ -440,5 +440,5 @@ let _ =
>   raise exc
>   done;
>   info "stopping xenstored";
> - DB.to_file store cons "/var/run/xenstored/db";
> + DB.to_file store cons (Paths.xen_run_stored ^ "/db");
>   ()
> -- 
> 2.1.4
> 


This also looks fine to me

Acked-by: David Scott 


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

Re: [Xen-devel] [PATCH 15/17] ocaml/libxs: honour XEN_RUN_STORED

[David Scott]

> On 13 Jun 2016, at 08:49, Wei Liu  wrote:
> 
> Signed-off-by: Wei Liu 
> ---
> Cc: Ian Jackson 
> Cc: David Scot 
> ---
> tools/ocaml/libs/xs/xs.ml | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/ocaml/libs/xs/xs.ml b/tools/ocaml/libs/xs/xs.ml
> index 7e14487..db9959a 100644
> --- a/tools/ocaml/libs/xs/xs.ml
> +++ b/tools/ocaml/libs/xs/xs.ml
> @@ -147,7 +147,7 @@ let monitor_paths xsh l time callback =
>   end;
>   unwatch ()
> 
> -let daemon_socket = "/var/run/xenstored/socket"
> +let daemon_socket = Paths.xen_run_stored ^ "/socket"
> 
> (** Throws this rather than a miscellaneous Unix.connect failed *)
> exception Failed_to_connect
> -- 
> 2.1.4
> 

This looks fine to me

Acked-by: David Scott 


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

Re: [Xen-devel] Next 4.6.x stable release, numbering, qemu-tag

[Konrad Rzeszutek Wilk]

> And, we ought not to let this issue delay the actual point release and
> it is close to being on the critical path.  A decision is needed.

My personal preferred color is 4.6.2.1 (and I believe we did a similar
release in the past: RELEASE-4.1.6.1)

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

Re: [Xen-devel] [PATCH 1/1] tools/livepatch: cleanup unnecessary "j = ARRAY_SIZE(action_options); "

[Olaf Hering]

On Fri, Jun 10, Dongli Zhang wrote:

> Local variable "j" would be used only when "i == ARRAY_SIZE(main_options)"
> is true. Thus, it is not necessary to update "j" when "i ==
> ARRAY_SIZE(main_options)" is false.

This breaks the build with gcc45:

[  153s] cc1: warnings being treated as errors
[  153s] xen-livepatch.c: In function 'main':
[  153s] xen-livepatch.c:415:12: error: 'j' may be used uninitialized in this 
function
[  153s] make[3]: *** [xen-livepatch.o] Error 1

Olaf

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

Re: [Xen-devel] [PATCH 02/15] flask/policy: split out rules for system_r

[Konrad Rzeszutek Wilk]

On Thu, Jun 09, 2016 at 10:47:05AM -0400, Daniel De Graaf wrote:
> When the all_system_role module is enabled, any domain type can be
> created using the system_r role, which was the default.  When it is
> disabled, domains not using the default types (dom0_t and domU_t) must
> use another role such as vm_r.
> 
> Signed-off-by: Daniel De Graaf 

Reviewed-by: Konrad Rzeszutek Wilk 

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

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

[osstest service owner]

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

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  9b394b7eff681fc1b4c88d9dec88ed38ebf8c456
baseline version:
 xen  5e02972646132ad98c365ebfcfcb43b40a0dde36

Last test of basis95662  2016-06-13 14:03:37 Z1 days
Failing since 95722  2016-06-14 14:18:38 Z0 days2 attempts
Testing same since95732  2016-06-14 17:09:50 Z0 days1 attempts


People who touched revisions under test:
  David Scott 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Kevin Tian 
  Quan Xu 
  Suravee Suthikulpanit 
  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=9b394b7eff681fc1b4c88d9dec88ed38ebf8c456
+ . ./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 
9b394b7eff681fc1b4c88d9dec88ed38ebf8c456
+ branch=xen-unstable-smoke
+ revision=9b394b7eff681fc1b4c88d9dec88ed38ebf8c456
+ . ./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.7-testing
+ '[' x9b394b7eff681fc1b4c88d9dec88ed38ebf8c456 = 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 

Re: [Xen-devel] [PATCH 01/15] flask/policy: split into modules

[Konrad Rzeszutek Wilk]

On Thu, Jun 09, 2016 at 10:47:04AM -0400, Daniel De Graaf wrote:
> This makes it easier to enable or disable parts of the XSM policy.
> 
> Signed-off-by: Daniel De Graaf 

Reviewed-by: Konrad Rzeszutek Wilk 

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

[Xen-devel] Next 4.6.x stable release, numbering, qemu-tag

[Ian Jackson]

We still have an unanswered question about the forthcoming 4.6.x
stable release.  To summarise:

After tagging qemu-xen-4.6.2, a build issue was discovered: qemu-xen
wanted a new patch to fix the build on recent Ubuntu.  We decided to
include this patch in the forthcoming stable point release of Xen 4.6.
So we will need to retag qemu-xen as part of the release process.

In my view the correct thing to do in this situation is to skip the
version number.  This is also, I think, quite conventional in other
projects, if new release-critical changes are discovered during the
release preparation.

I think it would be quite wrong to "release 4.6.2 with qemu-xen
c5fbb56ac828".  Indeed, I think it is now impossible to do a correct
release of 4.6.2 containing qemu-xen c5fbb56ac828, because making a
release of Xen (including a stable point release) involves making a
corresponding tag in the qemu trees.

Those corresponding tags are not just a technical link to Config.mk,
used by build automation.  They also have an independent existence.
They are PGP signed.  They can be verified outside the context of
xen.git's Config.mk.  They are looked at by humans.  git-describe uses
them.  Xen-specific automation might pick them up, knowing our tag
naming conventions.

We should therefore discard the version number 4.6.2 and proceed with
the forthcoming point release as 4.6.3.  Integers are plentiful and it
does not matter if we waste one, particularly in the point release
number.  We can mention briefly somewhere (release notes maybe) that
we skipped 4.6.2 because we discovered a patch we wanted to include,
while we were in the process of preparing the release.

We have spoken about this informally and it seems that Jan, the
primary stable tree maintainer, does not agree (or at least, has not
yet been convinced).

This may seem like a bikeshed issue to some.  But, I'm afraid that I
am very reluctant to do as Jan proposes, and proceed with a 4.6.2
release referring to a qemu tag such as qemu-xen-4.6.2.1 or 4.6.2b or
something.  Before doing that I would feel the need to escalate this
question to the Xen Project Committers (CC'd).

And, we ought not to let this issue delay the actual point release and
it is close to being on the critical path.  A decision is needed.

Thanks for your attention.

Ian.

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

Re: [Xen-devel] "xl vcpu-set" not persistent across reboot?

[Anthony PERARD]

On Tue, Jun 14, 2016 at 05:57:00PM +0100, Ian Jackson wrote:
> Wei Liu writes ("Re: [Xen-devel] "xl vcpu-set" not persistent across 
> reboot?"):
> > What Andrew means is that QEMU shouldn't have kept the CPU state
> > structures in the first place. My response explains why that is not
> > possible from a QEMU upstream point of view.
> 
> I don't think it addresses my point.
> 
> > Hence the unfortunate fact is that we need to live with it for now. To
> > start QEMU we need to create a bunch of dummy CPUs to keep QEMU happy.
> > All those dummy states need to be kept.
> 
> Why do we need one dummy state per actual vcpu rather than just one
> dummy state no matter how many vcpus ?
> 
> Or is qemu involved in hvm cpu hotplug ?

It is, QEMU does the notification to the guest of a newly available CPU
via an ACPI GPE or something like that. I think QEMU manage the bitfield
of online CPUs then notify the guest about changes.

-- 
Anthony PERARD

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

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

[osstest service owner]

flight 95663 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95663/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i3863 host-install(3) broken REGR. vs. 80927
 build-amd64   3 host-install(3) broken REGR. vs. 80927
 build-i386-pvops  3 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-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 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-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 build-i386-libvirt1 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-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-pygrub   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-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pv   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  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-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-pv1 build-check(1)   blocked  n/a

version targeted for testing:
 qemuu12e8fccf5b5460be7aecddc71d27eceaba6e1f15
baseline version:
 qemuu10c1b763c26feb645627a1639e722515f3e1e876

Last test of basis80927  2016-02-06 13:30:02 Z  129 days
Failing since 93977  2016-05-10 11:09:16 Z   35 days  123 attempts
Testing same since95534  2016-06-11 00:59:46 Z3 days3 attempts


People who touched revisions under test:
  Anthony PERARD 
  Gerd Hoffmann 
  Ian Jackson 
  Stefano Stabellini 
  Wei Liu 

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

Re: [Xen-devel] xenbits "official" repo for XTF (was Re: [PATCH 0/2] xtf: add launcher (+1 bugfix)

[Andrew Cooper]

On 13/06/16 15:11, Ian Jackson wrote:
> George Dunlap writes ("Re: [Xen-devel] xenbits "official" repo for XTF (was 
> Re: [PATCH 0/2] xtf: add launcher (+1 bugfix)"):
>> On Mon, Jun 13, 2016 at 11:10 AM, Andrew Cooper
>>> I am not completely averse to changing it, but I don't see an
>>> alternative which is any better or clearer.
>> Do you have any opinions on "Xen verification framework"?
> The problem IMO is the word "framework" which implies some kind of
> daemonic machinery.

I disagree.  Framework implies building blocks.

I can't see any implication or suggestion of daemonic machinery here.

> The frameworky bit of XTF is quite small; mostly,
> it is a suite of test cases.  "Xen Micro-VM Test Suite" maybe ?

At the moment, the framework is larger than the suite, although I don't
necessarily expect this to remain the case.  Having said that, I would
argue that the "framework" is the more important part; It is the bit
with the complicated logic to build the same code into multiple
different VM types, and APIs to make test reporting easy and consistent.

>
> (I think "verification" is inaccurate because to me it implies formal
> methods, static analysis, or the like.)

I concur.  "verification" is definitely a less accurate description.

>
>> If we weren't going to change it, then you should probably put a note
>> somewhere near the top of the introduction saying something like, "If
>> you're looking for the Xen automated push-gate software, you want
>> osstest[link]", so that people who want osstest but search for "xen
>> test framework" find what they're looking for.
> "CI (continuous integration)" is the keyword that many people will
> have for osstest.
>
> I would suggest
>
>   (This is not the Xen Project's CI / Continuous Integration /
>automated push gate system.  For that, see
>osstest.)
>
> or something.

I am happy to add text to that effect.

~Andrew



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

Re: [Xen-devel] "xl vcpu-set" not persistent across reboot?

[Wei Liu]

On Tue, Jun 14, 2016 at 06:03:01PM +0100, Wei Liu wrote:
> On Tue, Jun 14, 2016 at 05:57:00PM +0100, Ian Jackson wrote:
> > Wei Liu writes ("Re: [Xen-devel] "xl vcpu-set" not persistent across 
> > reboot?"):
> > > What Andrew means is that QEMU shouldn't have kept the CPU state
> > > structures in the first place. My response explains why that is not
> > > possible from a QEMU upstream point of view.
> > 
> > I don't think it addresses my point.
> > 
> > > Hence the unfortunate fact is that we need to live with it for now. To
> > > start QEMU we need to create a bunch of dummy CPUs to keep QEMU happy.
> > > All those dummy states need to be kept.
> > 
> > Why do we need one dummy state per actual vcpu rather than just one
> > dummy state no matter how many vcpus ?
> > 
> 
> We can't because ...
> 
> > Or is qemu involved in hvm cpu hotplug ?
> > 
> 
> when doing hotplug, libxl uses QMP command to tell QEMU to create
> CPUs.
> 
> Whether this can be changed I will let Anthony and Stefano to answer.
> 

OK, a quick check shows that the current state of affairs does require
QEMU to get involved.

If we skip the QMP call, guest gets no new cpus -- CPU hotplug is
completely broken.

Wei.

---8<---
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 0e2c15a..1cd8e00 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -5756,6 +5756,8 @@ static int libxl__set_vcpuonline_qmp(libxl__gc
*gc, uint32_t domid,
 int i, rc;
 libxl_bitmap current_map, final_map;
 
+return 0;
+
 libxl_bitmap_init(_map);
 libxl_bitmap_init(_map);

> Wei.
> 
> > Ian.

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

Re: [Xen-devel] "xl vcpu-set" not persistent across reboot?

[Wei Liu]

On Tue, Jun 14, 2016 at 05:59:30PM +0100, Andrew Cooper wrote:
> On 14/06/16 17:57, Ian Jackson wrote:
> > Wei Liu writes ("Re: [Xen-devel] "xl vcpu-set" not persistent across 
> > reboot?"):
> >> What Andrew means is that QEMU shouldn't have kept the CPU state
> >> structures in the first place. My response explains why that is not
> >> possible from a QEMU upstream point of view.
> > I don't think it addresses my point.
> >
> >> Hence the unfortunate fact is that we need to live with it for now. To
> >> start QEMU we need to create a bunch of dummy CPUs to keep QEMU happy.
> >> All those dummy states need to be kept.
> > Why do we need one dummy state per actual vcpu rather than just one
> > dummy state no matter how many vcpus ?
> >
> > Or is qemu involved in hvm cpu hotplug ?
> 
> Qemu has nothing to do with vcpus at all, and should not have vcpu state
> in its migration stream when acting as a device model.
> 
> Someone needs to fix this upstream in Qemu, and that is the *only*
> viable option here.
> 

Correct me if I'm wrong -- are you suggesting to add a board / platform
without any CPU to QEMU? If that's the suggestion I think QEMU
maintainers have made clear they won't accept such thing.

Wei.

> ~Andrew

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

Re: [Xen-devel] xenbits "official" repo for XTF (was Re: [PATCH 0/2] xtf: add launcher (+1 bugfix)

[Konrad Rzeszutek Wilk]

On Thu, Jun 09, 2016 at 04:04:59PM +0100, Ian Jackson wrote:
> Roger Pau Monne writes ("[Xen-devel] [PATCH 0/2] xtf: add launcher (+1 
> bugfix)"):
> > This series contains a bugfix for the build infrastructure and a basic 
> > launcher for XTF. Patches can also be found in the following git repo:
> > 
> > git://xenbits.xen.org/people/royger/xen-test-framework.git launcher_v1
> 
> IMO we should give this thing a proper repo in the root of the xenbits
> git namespace.
> 
> I'm slightly concerned that `xen-test-framework' is a bit vague.  It
> sounds like a CI system (of which we already have at least three ...),
> rather than a collection of tests based on tiny VMs, each designed to
> make specific demands of the host environment.

xtf-os.git ?

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

Re: [Xen-devel] [PATCH 10/17] build: introduce XEN_RUN_STORED

[Ian Jackson]

Wei Liu writes ("[PATCH 10/17] build: introduce XEN_RUN_STORED"):
> It defaults to /var/run/xenstored. It will be used later to remove some
> hard-coded paths in tree. There should be no visible change to default
> configuration.

Acked-by: Ian Jackson 

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

Re: [Xen-devel] "xl vcpu-set" not persistent across reboot?

[Andrew Cooper]

On 14/06/16 17:57, Ian Jackson wrote:
> Wei Liu writes ("Re: [Xen-devel] "xl vcpu-set" not persistent across 
> reboot?"):
>> What Andrew means is that QEMU shouldn't have kept the CPU state
>> structures in the first place. My response explains why that is not
>> possible from a QEMU upstream point of view.
> I don't think it addresses my point.
>
>> Hence the unfortunate fact is that we need to live with it for now. To
>> start QEMU we need to create a bunch of dummy CPUs to keep QEMU happy.
>> All those dummy states need to be kept.
> Why do we need one dummy state per actual vcpu rather than just one
> dummy state no matter how many vcpus ?
>
> Or is qemu involved in hvm cpu hotplug ?

Qemu has nothing to do with vcpus at all, and should not have vcpu state
in its migration stream when acting as a device model.

Someone needs to fix this upstream in Qemu, and that is the *only*
viable option here.

~Andrew

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

Re: [Xen-devel] "xl vcpu-set" not persistent across reboot?

[Ian Jackson]

Wei Liu writes ("Re: [Xen-devel] "xl vcpu-set" not persistent across reboot?"):
> What Andrew means is that QEMU shouldn't have kept the CPU state
> structures in the first place. My response explains why that is not
> possible from a QEMU upstream point of view.

I don't think it addresses my point.

> Hence the unfortunate fact is that we need to live with it for now. To
> start QEMU we need to create a bunch of dummy CPUs to keep QEMU happy.
> All those dummy states need to be kept.

Why do we need one dummy state per actual vcpu rather than just one
dummy state no matter how many vcpus ?

Or is qemu involved in hvm cpu hotplug ?

Ian.

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

Re: [Xen-devel] [PATCH] tools: bump some library version numbers to 4.8

[Ian Jackson]

Wei Liu writes ("[PATCH] tools: bump some library version numbers to 4.8"):
> It is a pretty safe thing to do and would avoid accidentally overwrite
> the old libraries when doing development.

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH v5 1/2] x86/mem-sharing: Bulk mem-sharing entire domains

[Tamas K Lengyel]

On Jun 14, 2016 10:33, "Konrad Rzeszutek Wilk" 
wrote:
>
> > diff --git a/xen/arch/x86/mm/mem_sharing.c
b/xen/arch/x86/mm/mem_sharing.c
> > index a522423..ba06fb0 100644
> > --- a/xen/arch/x86/mm/mem_sharing.c
> > +++ b/xen/arch/x86/mm/mem_sharing.c
> > @@ -1294,6 +1294,54 @@ int relinquish_shared_pages(struct domain *d)
> >  return rc;
> >  }
> >
> > +static int bulk_share(struct domain *d, struct domain *cd, unsigned
long limit,
> > +  struct mem_sharing_op_bulk *bulk)
> > +{
> > +int rc = 0;
> > +shr_handle_t sh, ch;
> > +
> > +while( limit > bulk->start )
>
> You are missing a space there.

Ack.

> > +{
> > +/*
> > + * We only break out if we run out of memory as individual
pages may
> > + * legitimately be unsharable and we just want to skip over
those.
> > + */
> > +rc = mem_sharing_nominate_page(d, bulk->start, 0, );
> > +if ( rc == -ENOMEM )
> > +break;
> > +if ( !rc )
> > +{
> > +rc = mem_sharing_nominate_page(cd, bulk->start, 0, );
> > +if ( rc == -ENOMEM )
> > +break;
> > +if ( !rc )
> > +{
> > +/* If we get here this should be guaranteed to
succeed. */
> > +rc = mem_sharing_share_pages(d, bulk->start, sh,
> > + cd, bulk->start, ch);
> > +ASSERT(!rc);
> > +}
> > +}
> > +
> > +/* Check for continuation if it's not the last iteration. */
> > +if ( limit > ++bulk->start && hypercall_preempt_check() )
>
> I surprised the compiler didn't complain to you about lack of parenthesis.

This seems to be standard way to create continuation used in multiple
places throughout Xen. I don't personally like it much but I guess it's
better to be consistent.

>
> > +{
> > +rc = 1;
> > +break;
> > +}
> > +}
> > +
> > +/*
> > + * We only propagate -ENOMEM as individual pages may fail with
-EINVAL,
> > + * and for bulk sharing we only care if -ENOMEM was encountered so
we reset
> > + * rc here.
> > + */
> > +if ( rc < 0 && rc != -ENOMEM )
> > +rc = 0;
> > +
> > +return rc;
> > +}
> > +
> >  int mem_sharing_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_sharing_op_t) arg)
> >  {
> >  int rc;
> > @@ -1468,6 +1516,79 @@ int
mem_sharing_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_sharing_op_t) arg)
> >  }
> >  break;
> >
> > +case XENMEM_sharing_op_bulk_share:
> > +{
> > +unsigned long max_sgfn, max_cgfn;
> > +struct domain *cd;
> > +
> > +rc = -EINVAL;
> > +if( mso.u.bulk._pad[0] || mso.u.bulk._pad[1] ||
mso.u.bulk._pad[2] )
>
> The "if("..

Ack.

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

Re: [Xen-devel] "xl vcpu-set" not persistent across reboot?

[Wei Liu]

On Tue, Jun 14, 2016 at 05:34:22PM +0100, Ian Jackson wrote:
> Wei Liu writes ("Re: [Xen-devel] "xl vcpu-set" not persistent across 
> reboot?"):
> > On Mon, Jun 06, 2016 at 06:34:44PM +0100, Andrew Cooper wrote:
> > > Why does qemu even care?  It has nothing to do with vcpu handling. 
> > > There should not be any qemu vcpu records in the first place.
> > 
> > IIRC upstream rejected the idea of having no cpu attached to a platform.
> 
> That doesn't explain why the number of vcpus that qemu believes in has
> to have anything to do with the number of vcpus that the guest has.
> 
> The qemu vcpu state is a dummy, regardless of how many of it there
> are, surely ?
> 

What Andrew means is that QEMU shouldn't have kept the CPU state
structures in the first place. My response explains why that is not
possible from a QEMU upstream point of view.

Hence the unfortunate fact is that we need to live with it for now. To
start QEMU we need to create a bunch of dummy CPUs to keep QEMU happy.
All those dummy states need to be kept.

The guest is irrelevant here. We don't care about what guest thinks, but
we need to keep toolstack side view consistent so that migration and
save / restore won't fail.

Wei.

> Ian.

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

Re: [Xen-devel] [PATCH 3/3] libxl: update vcpus bitmap in retrieved guest config

[Wei Liu]

On Tue, Jun 14, 2016 at 05:31:56PM +0100, Ian Jackson wrote:
> Wei Liu writes ("[PATCH 3/3] libxl: update vcpus bitmap in retrieved guest 
> config"):
> > ... because the available vcpu bitmap can change during domain life time
> > due to cpu hotplug and unplug.
> 
> Is this cpu hotplug something that the guest can cause, or are we just
> talking about toolstack changes ?
> 

We're only talking about toolstack side here.

Wei.

> Ian.

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

Re: [Xen-devel] "xl vcpu-set" not persistent across reboot?

[Ian Jackson]

Wei Liu writes ("Re: [Xen-devel] "xl vcpu-set" not persistent across reboot?"):
> On Mon, Jun 06, 2016 at 06:34:44PM +0100, Andrew Cooper wrote:
> > Why does qemu even care?  It has nothing to do with vcpu handling. 
> > There should not be any qemu vcpu records in the first place.
> 
> IIRC upstream rejected the idea of having no cpu attached to a platform.

That doesn't explain why the number of vcpus that qemu believes in has
to have anything to do with the number of vcpus that the guest has.

The qemu vcpu state is a dummy, regardless of how many of it there
are, surely ?

Ian.

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

Re: [Xen-devel] [PATCH v5 1/2] x86/mem-sharing: Bulk mem-sharing entire domains

[Konrad Rzeszutek Wilk]

> diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
> index a522423..ba06fb0 100644
> --- a/xen/arch/x86/mm/mem_sharing.c
> +++ b/xen/arch/x86/mm/mem_sharing.c
> @@ -1294,6 +1294,54 @@ int relinquish_shared_pages(struct domain *d)
>  return rc;
>  }
>  
> +static int bulk_share(struct domain *d, struct domain *cd, unsigned long 
> limit,
> +  struct mem_sharing_op_bulk *bulk)
> +{
> +int rc = 0;
> +shr_handle_t sh, ch;
> +
> +while( limit > bulk->start )

You are missing a space there.
> +{
> +/*
> + * We only break out if we run out of memory as individual pages may
> + * legitimately be unsharable and we just want to skip over those.
> + */
> +rc = mem_sharing_nominate_page(d, bulk->start, 0, );
> +if ( rc == -ENOMEM )
> +break;
> +if ( !rc )
> +{
> +rc = mem_sharing_nominate_page(cd, bulk->start, 0, );
> +if ( rc == -ENOMEM )
> +break;
> +if ( !rc )
> +{
> +/* If we get here this should be guaranteed to succeed. */
> +rc = mem_sharing_share_pages(d, bulk->start, sh,
> + cd, bulk->start, ch);
> +ASSERT(!rc);
> +}
> +}
> +
> +/* Check for continuation if it's not the last iteration. */
> +if ( limit > ++bulk->start && hypercall_preempt_check() )

I surprised the compiler didn't complain to you about lack of parenthesis.

> +{
> +rc = 1;
> +break;
> +}
> +}
> +
> +/*
> + * We only propagate -ENOMEM as individual pages may fail with -EINVAL,
> + * and for bulk sharing we only care if -ENOMEM was encountered so we 
> reset
> + * rc here.
> + */
> +if ( rc < 0 && rc != -ENOMEM )
> +rc = 0;
> +
> +return rc;
> +}
> +
>  int mem_sharing_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_sharing_op_t) arg)
>  {
>  int rc;
> @@ -1468,6 +1516,79 @@ int 
> mem_sharing_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_sharing_op_t) arg)
>  }
>  break;
>  
> +case XENMEM_sharing_op_bulk_share:
> +{
> +unsigned long max_sgfn, max_cgfn;
> +struct domain *cd;
> +
> +rc = -EINVAL;
> +if( mso.u.bulk._pad[0] || mso.u.bulk._pad[1] || 
> mso.u.bulk._pad[2] )

The "if("..

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

Re: [Xen-devel] [PATCH 3/3] libxl: update vcpus bitmap in retrieved guest config

[Ian Jackson]

Wei Liu writes ("[PATCH 3/3] libxl: update vcpus bitmap in retrieved guest 
config"):
> ... because the available vcpu bitmap can change during domain life time
> due to cpu hotplug and unplug.

Is this cpu hotplug something that the guest can cause, or are we just
talking about toolstack changes ?

Ian.

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

Re: [Xen-devel] [PATCH v2 2/3] libxl: update vcpus bitmap in retrieved guest config

[Ian Jackson]

Wei Liu writes ("Re: [PATCH v2 2/3] libxl: update vcpus bitmap in retrieved 
guest config"):
> On Tue, Jun 14, 2016 at 11:58:58AM +0100, Anthony PERARD wrote:
> > I did:
> > LD_LIBRARY_PATH=`pwd` ./xl -vvv migrate arch localhost
> 
> Never tried this so I'm not sure what might go wrong...

That is how I do most of my ad-hoc testing.

If you have a newer xenstore etc. too you may need something like
  LD_LIBRARY_PATH=../xenstore:.

I find that relative paths work well with xl (because libxl is not
entitled to chdir, and xl doesn't).

Ian.

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

[Xen-devel] [xen-unstable-smoke test] 95722: trouble: broken/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-debianhvm-i386 3 host-install(3) broken REGR. vs. 
95662

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  fcf3f57c54091c3d5d3b00390c802345da4d
baseline version:
 xen  5e02972646132ad98c365ebfcfcb43b40a0dde36

Last test of basis95662  2016-06-13 14:03:37 Z1 days
Testing same since95722  2016-06-14 14:18:38 Z0 days1 attempts


People who touched revisions under test:
  David Scott 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Kevin Tian 
  Quan Xu 
  Suravee Suthikulpanit 
  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 broken  
 test-amd64-amd64-libvirt pass



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

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

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

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

broken-step test-amd64-amd64-xl-qemuu-debianhvm-i386 host-install(3)

Not pushing.


commit fcf3f57c54091c3d5d3b00390c802345da4d
Author: Wei Liu 
Date:   Mon Jun 13 08:49:06 2016 +0100

tools: remove hard-coded /var/lib/xen in Makefile

Now all conversations are done, remove the hard-coded paths.

Signed-off-by: Wei Liu 
Acked-by: Ian Jackson 

commit 938b2b4033bded8b0f6ec7298684dcd6235d4de3
Author: Wei Liu 
Date:   Mon Jun 13 08:49:05 2016 +0100

libxl: honour XEN_LIB_DIR

Signed-off-by: Wei Liu 
Acked-by: Ian Jackson 
;wq

commit 540cecf0cf066ad0386993c8e625006b259c0df8
Author: Wei Liu 
Date:   Mon Jun 13 08:49:04 2016 +0100

hotplug/Linux: honour XEN_LIB_DIR

Use configure to generate sysconfig.xendomains file.

Signed-off-by: Wei Liu 
Acked-by: Ian Jackson 

commit 102ddb11f243e4ee01592e91afb23a651c7023d3
Author: Wei Liu 
Date:   Mon Jun 13 08:49:03 2016 +0100

tools: install and remove XEN_LIB_DIR in Makefile

The intention of using wild card in uninstall target is to remove both
xen and xenstored directories. Change that to two runes that explicitly
remove each of those directories.

Note that the runes that use hard-coded paths are kept for now to keep
the tree bisectable as I replace hard-coded paths component by
component.  Those runes will be removed eventually.

Signed-off-by: Wei Liu 
Acked-by: Ian Jackson 

commit 15f1a11d66170baa0d62131586d29429c758a1be
Author: Wei Liu 
Date:   Mon Jun 13 08:49:02 2016 +0100

build: introduce and export XEN_LIB_DIR

This variable defaults to /var/lib/xen. It will be used to substitute
various hard-coded paths in tools.

The new variable points to $localstatedir/lib/xen, which defaults to
/var/lib/xen, so there is no change in default configuration.

Signed-off-by: Wei Liu 
Acked-by: Ian Jackson 

commit a4fa83e5684e4aab33676748e79a884f3d0f86ff
Author: Wei Liu 
Date:   Mon Jun 13 08:49:01 2016 +0100

oxenstored: honour XEN_LOG_DIR defined by configure

We generate a corresponding constant (in lower case) in paths.ml. Use
that in source code to get 

Re: [Xen-devel] [PULL 0/2] xen-20160614-tag

[Peter Maydell]

On 14 June 2016 at 16:04, Stefano Stabellini <sstabell...@kernel.org> wrote:
> The following changes since commit 55e5c3a2d2433bd2e1e635a7ba395f1c70341794:
>
>   Merge remote-tracking branch 
> 'remotes/berrange/tags/qcrypto-next-2016-06-13-v1' into staging (2016-06-13 
> 13:05:02 +0100)
>
> are available in the git repository at:
>
>
>   git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-20160614-tag
>
> for you to fetch changes up to b1b23e5bbfb66d9401e2c2b0646fb721d94a3f83:
>
>   xen: Clean up includes (2016-06-14 15:37:43 +0100)
>
> 
> Xen 2016/06/14
>
> 
> Jan Beulich (1):
>   xen/blkif: avoid double access to any shared ring request fields
>
> Peter Maydell (1):
>   xen: Clean up includes
>
>  hw/block/xen_blkif.h | 12 ++--
>  hw/block/xen_disk.c  |  2 ++
>  hw/usb/xen-usb.c |  5 +
>  include/hw/xen/xen.h |  1 -
>  4 files changed, 9 insertions(+), 11 deletions(-)

Applied, thanks.

-- PMM

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

Re: [Xen-devel] Question about sharing spinlock_t among VMs in Xen

[Andrew Cooper]

On 14/06/16 03:13, Meng Xu wrote:
> On Mon, Jun 13, 2016 at 6:54 PM, Andrew Cooper
>  wrote:
>> On 13/06/2016 18:43, Meng Xu wrote:
>>> Hi,
>>>
>>> I have a quick question about using the Linux spin_lock() in Xen
>>> environment to protect some host-wide shared (memory) resource among
>>> VMs.
>>>
>>> *** The question is as follows ***
>>> Suppose I have two Linux VMs sharing the same spinlock_t lock (through
>>> the sharing memory) on the same host. Suppose we have one process in
>>> each VM. Each process uses the linux function spin_lock() [1] to
>>> grab & release the lock.
>>> Will these two processes in the two VMs have race on the shared lock?
>> "Race" is debatable.  (After all, the point of a lock is to have
>> serialise multiple accessors).  But yes, this will be the same lock.
>>
>> The underlying cache coherency fabric will perform atomic locked
>> operations on the same physical piece of RAM.
> The experiment we did is on a computer that is not NUMA.

Why do you think this makes any difference?  Unless you have a
uni-processor system from ages ago, there will be cache coherency being
done in hardware.

> So it should not be caused by the sync. issue in hardware.

I do not understand what you are trying to say here.

>
>> The important question is whether the two difference VMs have an
>> identical idea of what a spinlock_t is.  If not, this will definitely fail.
> I see the key point here now. However, I'm not that sure about if the
> two VMs have an *identical idea* of what a spinlock_t is.

If you are not sure, then the answer is almost certainly no.

> In otherwords, how to tell "if two VMs have an identical idea of what a
> spinlock_t is"?

Is struct spinlock_t, and all functions which modify it, identical
between all VMs trying to participate in the use of this shared memory
spinlock?

>
> The current situation is as follows:
> Both VMs are using the same memory area for the spinlock_t variable.
> The spin_lock() in both VMs are operating on the same spinlock_t
> variable. So IMHO, the spinlock_t should be identical to these two
> VMs?
> Please correct me if I'm wrong. (I guess my understanding of the
> "identical idea of spinlock_t" may probably be incorrect. :-( )
>
>>> My speculation is that it should have the race on the shard lock when
>>> the spin_lock() function in *two VMs* operate on the same lock.
>>>
>>> We did some quick experiment on this and we found one VM sometimes see
>>> the soft lockup on the lock. But we want to make sure our
>>> understanding is correct.
>>>
>>> We are exploring if we can use the spin_lock to protect the shared
>>> resources among VMs, instead of using the PV drivers. If the
>>> spin_lock() in linux can provide the host-wide atomicity (which will
>>> surprise me, though), that will be great. Otherwise, we probably have
>>> to expose the spin_lock in Xen to the Linux?
>> What are you attempting to protect like this?
> For example, if two VMs are sharing a chunk of memory with both read
> and write permissions, a VM has to grab the lock before it can operate
> on the shared memory.
> If we want a VM directly operate on the shared resource, instead of
> using the PV device model, we may need to use spinlock to protect the
> access to the shared resource. That's why we are looking at the
> spinlock.
>
>> Anything which a guest can spin on like this is a recipe for disaster,
>> as you observe, as the guest which holds the lock will get scheduled out
>> in favour of the guest attempting to take the lock.
> It is true in general. The reason why we choose to let it spin is
> because some people in academia propose the protocols to access the
> shared resource through spinlock. In order to apply their theory, we
> may need to follow the system model they assumed. The theory did
> consider the situation when a guest/VCPU that is spinning on a lock is
> schedule out. The theory has to consider the extra delay caused by
> this situation. [OK. This is the reason why we did like this. But we
> are also thinking if we can do better in terms of the overall system
> performance.]
>
> BTW, I agree with you that letting guest spin like this could be a
> problem for the overall system performance.
>
>> Alternatively, two
>> different guests with a different idea of how to manage the memory
>> backing a spinlock_t.
> Just to confirm:
> Did you mean that different guests will use different policies to
> handle the same spinlock_t?
> This may mean that we need to have some special locking protocol,
> instead of the ticket_lock to handle the spin_lock?
>
> For example, a very simple and probably naive idea is that we may let
> a guest not be scheduled out before it releases the lock. I just want
> to use this simple example to make sure I understood the "alternative"
> idea here. :-)

A guest is not in control of when it gets descheduled, and you cant yank
a lock while the guest is in a critical region.

If you want to proceed down this route, you 

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-xsm   3 host-install(3) broken REGR. vs. 95446
 test-amd64-i386-xl-xsm3 host-install(3) broken REGR. vs. 95446
 test-amd64-i386-xl-qemut-winxpsp3  3 host-install(3)broken REGR. vs. 95446
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 15 guest-localmigrate/x10 fail REGR. 
vs. 95446

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail REGR. vs. 95446
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail REGR. vs. 95446
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 95446

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
 build-i386-rumpuserxen6 xen-buildfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 build-amd64-rumpuserxen   6 xen-buildfail   never pass
 test-amd64-amd64-xl-pvh-amd  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-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   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-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail 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-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-amd64-i386-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-xl-qemut-win7-amd64 16 guest-stop fail never pass
 test-amd64-amd64-libvirt-vhd 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-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 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-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail 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-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  81722e7d443d33f48416c31f03ab4c2a9ba54b23
baseline version:
 xen  c2a17869d5dcd845d646bf4db122cad73596a2be

Last test of basis95446  2016-06-08 16:21:53 Z5 days
Failing since 95489  2016-06-10 02:58:16 Z4 days3 attempts
Testing same since95653  2016-06-13 11:31:56 Z1 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Anil Madhavapeddy 
  Christoph Egger 
  Daniel De Graaf 
  Doug Goldstein 
  Euan Harris 
  George Dunlap 
  Haozhong Zhang 
  Ian Jackson 
  Jan Beulich 
  Jason Andryuk 
  Jiandi An 
 

Re: [Xen-devel] [PATCH 3/3] Update README.md

[Konrad Rzeszutek Wilk]

On Fri, Jun 10, 2016 at 12:02:45PM +0100, Ross Lagerwall wrote:
> Update the example and project status. Add Contributing and Maintainers
> sections.

Reviewed-by: Konrad Rzeszutek Wilk 
> 
> Signed-off-by: Ross Lagerwall 
> ---
>  README.md | 76 
> ---
>  1 file changed, 53 insertions(+), 23 deletions(-)
> 
> diff --git a/README.md b/README.md
> index 9fb709f..653c624 100644
> --- a/README.md
> +++ b/README.md
> @@ -2,27 +2,34 @@ livepatch-build
>  =
>  
>  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
> +patches.  It takes as input, a Xen tree and a patch and outputs a
>  `.livepatch` module containing containing the live patch.
>  
>  Quick start
>  ---
>  First checkout the code, and then run `make` to build it.
>  
> -Here is an example of building a patch for XSA-106:
> +Here is an example of building a live patch for Xen for some XSA.
> +First build Xen, install it on a host somewhere and reboot:
> +```
> +$ cp -r ~/src/xen ~/src/xenbuild
> +$ cd ~/src/xen/xen
> +$ make nconfig # Make sure to set CONFIG_LIVEPATCH=y
> +$ make
> +$ BUILDID=$(readelf -Wn xen-syms | awk '/Build ID:/ {print $3}')
> +```
> +
> +Next, build a live patch, using a patch and the source, build ID, and
> +.config from the original build:
>  ```
> -$ cd ~/src/xen
> -$ git reset --hard
> -$ git clean -x -f -d
> -$ git checkout 346d4545569928b652c40c7815c1732676f8587c^
>  $ cd ~/src/livepatch-build
> -$ wget -q 'http://xenbits.xen.org/xsa/xsa106.patch'
> -$ ./livepatch-build --xen-debug -s ~/src/xen -p xsa106.patch -o out
> -Building LivePatch patch: xsa106
> +$ ./livepatch-build -s ~/src/xenbuild -p ~/src/xsa.patch -o out \
> +-c ~/src/xen/xen/.config --depends $BUILDID
> +Building LivePatch patch: xsa
>  
> -Xen directory: /home/ross/src/xen
> -Patch file: /home/ross/src/livepatch-build/xsa106.patch
> -Output directory: /home/ross/src/livepatch-build/out
> +Xen directory: /home/ross/src/xenbuild
> +Patch file: /home/ross/src/xsa.patch
> +Output directory: /home/ross/src/livepatch-build-tools/out
>  
>  
>  Testing patch file...
> @@ -32,22 +39,45 @@ 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.livepatch created successfully
> +xsa.livepatch created successfully
>  
> -$ ls -lh out/xsa106.livepatch
> --rw-rw-r--. 1 ross ross 418K Oct 12 12:02 out/xsa106.livepatch
> +$ ls -lh out/xsa.livepatch
> +-rwxrwxr-x. 1 ross ross 135K Jun 10 09:32 out/xsa.livepatch
> +```
> +
> +Finally, copy the live patch to the host and load it:
> +```
> +$ scp out/xsa.livepatch myhost:
> +$ ssh myhost 'xen-livepatch load xsa.livepatch'
> +Uploading xsa.livepatch (135840 bytes)
> +Performing apply:. completed
> +$ ssh myhost 'xen-livepatch list'
> + ID | status
> ++
> +xsa | APPLIED
>  ```
>  
>  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 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,
> -XSA-112, and XSA-114 (83% success rate).
> +Live patches can be built and applied for many changes, including most
> +XSAs; however, there are still some cases which require changing the
> +source patch to allow it to be built as a live patch.
> +
> +This tool currently supports x86 only.
> +
> +It is intended that some or all of this project will merge back into
> +kpatch-build rather being maintained as a fork.
> +
> +Contributing
> +
> +Please send patches created with `git-format-patch` and an appropriate
> +Signed-off-by: line to , CCing the maintainers
> +listed below.
> +
> +Maintainers
> +---
> +* Ross Lagerwall 
> +* Konrad Rzeszutek Wilk 
>  
>  License
>  ---
> -- 
> 2.4.11
> 

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

Re: [Xen-devel] [PATCH 2/3] Update to use a .config file

[Konrad Rzeszutek Wilk]

On Fri, Jun 10, 2016 at 12:02:44PM +0100, Ross Lagerwall wrote:
> Remove the old --xen-debug option, and instead, require the user to pass
> a .config file matching the original build's .config.

Hm, that throws this off a bit for the older hypervisors (to which
I had backported livepatch). Perhaps we could add some logic to
check if common/Kconfig exist? 

And I also wonder if the --xen-debug option removal should be a seperate
patch?

> 
> Signed-off-by: Ross Lagerwall 
> ---
>  livepatch-build | 24 
>  1 file changed, 16 insertions(+), 8 deletions(-)
> 
> diff --git a/livepatch-build b/livepatch-build
> index 8dc8889..e9d1e8d 100755
> --- a/livepatch-build
> +++ b/livepatch-build
> @@ -66,7 +66,7 @@ function build_full()
>  {
>  cd "${SRCDIR}/xen" || die
>  make "-j$CPUS" clean &> "${OUTPUT}/build_full_clean.log" || die
> -make "-j$CPUS" debug="$XEN_DEBUG" &> "${OUTPUT}/build_full_compile.log" 
> || die
> +make "-j$CPUS" &> "${OUTPUT}/build_full_compile.log" || die
>  cp xen-syms "$OUTPUT"
>  }
>  
> @@ -86,7 +86,7 @@ function build_special()
>  # Build with special GCC flags
>  cd "${SRCDIR}/xen" || die
>  sed -i 's/CFLAGS += -nostdinc/CFLAGS += -nostdinc -ffunction-sections 
> -fdata-sections/' Rules.mk
> -make "-j$CPUS" debug="$XEN_DEBUG" &> 
> "${OUTPUT}/build_${name}_compile.log" || die
> +make "-j$CPUS" &> "${OUTPUT}/build_${name}_compile.log" || die
>  sed -i 's/CFLAGS += -nostdinc -ffunction-sections -fdata-sections/CFLAGS 
> += -nostdinc/' Rules.mk
>  
>  unset LIVEPATCH_BUILD_DIR
> @@ -158,17 +158,17 @@ usage() {
>  echo "-h, --help Show this help message" >&2
>  echo "-s, --srcdir   Xen source directory" >&2
>  echo "-p, --patchPatch file" >&2
> +echo "-c, --config   .config file" >&2
>  echo "-o, --output   Output directory" >&2
>  echo "-j, --cpus Number of CPUs to use" >&2
>  echo "-k, --skip Skip build or diff phase" >&2
>  echo "-d, --debugEnable debug logging" >&2
> -echo "--xen-debugBuild debug Xen" >&2
>  echo "--xen-syms Build against a xen-syms" >&2
>  echo "--depends  Required build-id" >&2
>  echo "--prelink  Prelink" >&2
>  }
>  
> -options=$(getopt -o hs:p:o:j:k:d -l 
> "help,srcdir:patch:output:cpus:,skip:,debug,xen-debug,xen-syms:,depends:,prelink"
>  -- "$@") || die "getopt failed"
> +options=$(getopt -o hs:p:c:o:j:k:d -l 
> "help,srcdir:patch:config:output:cpus:,skip:,debug,xen-syms:,depends:,prelink"
>  -- "$@") || die "getopt failed"
>  
>  eval set -- "$options"
>  
> @@ -192,10 +192,6 @@ while [[ $# -gt 0 ]]; do
>  DEBUG=1
>  shift
>  ;;
> ---xen-debug)
> -XEN_DEBUG=y
> -shift
> -;;
>  -s|--srcdir)
>  shift
>  srcarg="$1"
> @@ -206,6 +202,11 @@ while [[ $# -gt 0 ]]; do
>  patcharg="$1"
>  shift
>  ;;
> +-c|--config)
> +shift
> +configarg="$1"
> +shift
> +;;
>  -o|--output)
>  shift
>  outputarg="$1"
> @@ -235,15 +236,18 @@ done
>  
>  [ -z "$srcarg" ] && die "Xen directory not given"
>  [ -z "$patcharg" ] && die "Patchfile not given"
> +[ -z "$configarg" ] && die ".config not given"
>  [ -z "$outputarg" ] && die "Output directory not given"
>  [ -z "$DEPENDS" ] && die "Build-id dependency not given"
>  
>  SRCDIR="$(readlink -m -- "$srcarg")"
>  PATCHFILE="$(readlink -m -- "$patcharg")"
> +CONFIGFILE="$(readlink -m -- "$configarg")"
>  OUTPUT="$(readlink -m -- "$outputarg")"
>  
>  [ -d "${SRCDIR}" ] || die "Xen directory does not exist"
>  [ -f "${PATCHFILE}" ] || die "Patchfile does not exist"
> +[ -f "${CONFIGFILE}" ] || die ".config does not exist"
>  
>  PATCHNAME=$(make_patch_name "${PATCHFILE}")
>  
> @@ -251,16 +255,20 @@ echo "Building LivePatch patch: ${PATCHNAME}"
>  echo
>  echo "Xen directory: ${SRCDIR}"
>  echo "Patch file: ${PATCHFILE}"
> +echo ".config file: ${CONFIGFILE}"
>  echo "Output directory: ${OUTPUT}"
>  echo ""
>  echo
>  
>  if [ "${SKIP}" != "build" ]; then
>  [ -e "${OUTPUT}" ] && die "Output directory exists"
> +grep -q 'CONFIG_LIVEPATCH=y' "${CONFIGFILE}" || die "CONFIG_LIVEPATCH 
> must be enabled"
>  cd "$SRCDIR" || die
>  patch -s -N -p1 -f --fuzz=0 --dry-run < "$PATCHFILE" || die "Source 
> patch file failed to apply"
>  
>  mkdir -p "${OUTPUT}" || die
> +cp -f "${CONFIGFILE}" "${OUTPUT}/.config"
> +cp -f "${OUTPUT}/.config" "xen/.config"
>  
>  echo "Perform full initial build with ${CPUS} CPU(s)..."
>  build_full
> -- 
> 2.4.11
> 

___
Xen-devel mailing 

Re: [Xen-devel] [PATCH 1/3] Don't accept fuzz when patching

[Konrad Rzeszutek Wilk]

On Fri, Jun 10, 2016 at 12:02:43PM +0100, Ross Lagerwall wrote:
> When testing and applying patches, set fuzz=0 so that patches must apply
> exactly.  Also set "-f" to avoid interactive questions, and reorder so
> that patches are tested before the output directory is created.
> 
> Signed-off-by: Ross Lagerwall 

Reviewed-by: Konrad Rzeszutek Wilk 
> ---
>  livepatch-build | 11 +--
>  1 file changed, 5 insertions(+), 6 deletions(-)
> 
> diff --git a/livepatch-build b/livepatch-build
> index a49e0d4..8dc8889 100755
> --- a/livepatch-build
> +++ b/livepatch-build
> @@ -257,23 +257,22 @@ echo
>  
>  if [ "${SKIP}" != "build" ]; then
>  [ -e "${OUTPUT}" ] && die "Output directory exists"
> -mkdir -p "${OUTPUT}" || die
> -
> -echo "Testing patch file..."
>  cd "$SRCDIR" || die
> -patch -s -N -p1 --dry-run < "$PATCHFILE" || die "source patch file 
> failed to apply"
> +patch -s -N -p1 -f --fuzz=0 --dry-run < "$PATCHFILE" || die "Source 
> patch file failed to apply"
> +
> +mkdir -p "${OUTPUT}" || die
>  
>  echo "Perform full initial build with ${CPUS} CPU(s)..."
>  build_full
>  
>  echo "Apply patch and build with ${CPUS} CPU(s)..."
>  cd "$SRCDIR" || die
> -patch -s -N -p1 < "$PATCHFILE" || die
> +patch -s -N -p1 -f --fuzz=0 < "$PATCHFILE" || die
>  build_special patched
>  
>  echo "Unapply patch and build with ${CPUS} CPU(s)..."
>  cd "$SRCDIR" || die
> -patch -s -R -p1 < "$PATCHFILE" || die
> +patch -s -R -p1 -f --fuzz=0 < "$PATCHFILE" || die
>  build_special original
>  fi
>  
> -- 
> 2.4.11
> 

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

Re: [Xen-devel] [PATCH] x86/HVM: rename mmio_gva field to mmio_gla

[Paul Durrant]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 14 June 2016 15:45
> To: xen-devel
> Cc: Andrew Cooper; Paul Durrant
> Subject: [PATCH] x86/HVM: rename mmio_gva field to mmio_gla
> 
> ... to correctly reflect its purpose. To make things consistent also
> rename handle_mmio_with_translation()'s respective parameter (but don't
> touch sh_page_fault(), as renaming its parameter would require quite a
> few more changes there).
> 
> Suggested-by: Andrew Cooper 
> Signed-off-by: Jan Beulich 
> 

Reviewed-by: Paul Durrant 

> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -684,7 +684,7 @@ static void latch_linear_to_phys(struct
>  if ( vio->mmio_access.gla_valid )
>  return;
> 
> -vio->mmio_gva = gla & PAGE_MASK;
> +vio->mmio_gla = gla & PAGE_MASK;
>  vio->mmio_gpfn = PFN_DOWN(gpa);
>  vio->mmio_access = (struct npfec){ .gla_valid = 1,
> .read_access = 1,
> @@ -782,7 +782,7 @@ static int __hvmemul_read(
>  if ( ((access_type != hvm_access_insn_fetch
> ? vio->mmio_access.read_access
> : vio->mmio_access.insn_fetch)) &&
> - (vio->mmio_gva == (addr & PAGE_MASK)) )
> + (vio->mmio_gla == (addr & PAGE_MASK)) )
>  return hvmemul_linear_mmio_read(addr, bytes, p_data, pfec,
> hvmemul_ctxt, 1);
> 
>  if ( (seg != x86_seg_none) &&
> @@ -889,7 +889,7 @@ static int hvmemul_write(
>  return rc;
> 
>  if ( vio->mmio_access.write_access &&
> - (vio->mmio_gva == (addr & PAGE_MASK)) )
> + (vio->mmio_gla == (addr & PAGE_MASK)) )
>  return hvmemul_linear_mmio_write(addr, bytes, p_data, pfec,
> hvmemul_ctxt, 1);
> 
>  if ( (seg != x86_seg_none) &&
> @@ -1181,7 +1181,7 @@ static int hvmemul_rep_movs(
> 
>  bytes = PAGE_SIZE - (saddr & ~PAGE_MASK);
>  if ( vio->mmio_access.read_access &&
> - (vio->mmio_gva == (saddr & PAGE_MASK)) &&
> + (vio->mmio_gla == (saddr & PAGE_MASK)) &&
>   bytes >= bytes_per_rep )
>  {
>  sgpa = pfn_to_paddr(vio->mmio_gpfn) | (saddr & ~PAGE_MASK);
> @@ -1200,7 +1200,7 @@ static int hvmemul_rep_movs(
> 
>  bytes = PAGE_SIZE - (daddr & ~PAGE_MASK);
>  if ( vio->mmio_access.write_access &&
> - (vio->mmio_gva == (daddr & PAGE_MASK)) &&
> + (vio->mmio_gla == (daddr & PAGE_MASK)) &&
>   bytes >= bytes_per_rep )
>  {
>  dgpa = pfn_to_paddr(vio->mmio_gpfn) | (daddr & ~PAGE_MASK);
> @@ -1320,7 +1320,7 @@ static int hvmemul_rep_stos(
> 
>  bytes = PAGE_SIZE - (addr & ~PAGE_MASK);
>  if ( vio->mmio_access.write_access &&
> - (vio->mmio_gva == (addr & PAGE_MASK)) &&
> + (vio->mmio_gla == (addr & PAGE_MASK)) &&
>   bytes >= bytes_per_rep )
>  {
>  gpa = pfn_to_paddr(vio->mmio_gpfn) | (addr & ~PAGE_MASK);
> --- a/xen/arch/x86/hvm/io.c
> +++ b/xen/arch/x86/hvm/io.c
> @@ -114,7 +114,7 @@ int handle_mmio(void)
>  return 1;
>  }
> 
> -int handle_mmio_with_translation(unsigned long gva, unsigned long gpfn,
> +int handle_mmio_with_translation(unsigned long gla, unsigned long gpfn,
>   struct npfec access)
>  {
>  struct hvm_vcpu_io *vio = >arch.hvm_vcpu.hvm_io;
> @@ -122,7 +122,7 @@ int handle_mmio_with_translation(unsigne
>  vio->mmio_access = access.gla_valid &&
> access.kind == npfec_kind_with_gla
> ? access : (struct npfec){};
> -vio->mmio_gva = gva & PAGE_MASK;
> +vio->mmio_gla = gla & PAGE_MASK;
>  vio->mmio_gpfn = gpfn;
>  return handle_mmio();
>  }
> --- a/xen/include/asm-x86/hvm/io.h
> +++ b/xen/include/asm-x86/hvm/io.h
> @@ -119,7 +119,7 @@ void relocate_portio_handler(
>  void send_timeoffset_req(unsigned long timeoff);
>  void send_invalidate_req(void);
>  int handle_mmio(void);
> -int handle_mmio_with_translation(unsigned long gva, unsigned long gpfn,
> +int handle_mmio_with_translation(unsigned long gla, unsigned long gpfn,
>   struct npfec);
>  int handle_pio(uint16_t port, unsigned int size, int dir);
>  void hvm_interrupt_post(struct vcpu *v, int vector, int type);
> --- a/xen/include/asm-x86/hvm/vcpu.h
> +++ b/xen/include/asm-x86/hvm/vcpu.h
> @@ -60,12 +60,12 @@ struct hvm_vcpu_io {
> 
>  /*
>   * HVM emulation:
> - *  Virtual address @mmio_gva maps to MMIO physical frame
> @mmio_gpfn.
> + *  Linear address @mmio_gla maps to MMIO physical frame
> @mmio_gpfn.
>   *  The latter is known to be an MMIO frame (not RAM).
>   *  This translation is only valid for accesses as per @mmio_access.
>   */
>  struct npfecmmio_access;
> -unsigned long   mmio_gva;
> +unsigned long   mmio_gla;
>  unsigned long   mmio_gpfn;
> 
>  /*
> 


___
Xen-devel mailing 

[Xen-devel] [PULL 2/2] xen: Clean up includes

[Stefano Stabellini]

From: Peter Maydell 

Clean up includes so that osdep.h is included first and headers
which it implies are not included manually.

This commit was created with scripts/clean-includes.

Signed-off-by: Peter Maydell 
Reviewed-by: Stefano Stabellini 
Signed-off-by: Stefano Stabellini 
---
 hw/usb/xen-usb.c | 5 +
 include/hw/xen/xen.h | 1 -
 2 files changed, 1 insertion(+), 5 deletions(-)

diff --git a/hw/usb/xen-usb.c b/hw/usb/xen-usb.c
index 664df04..8fa47ed 100644
--- a/hw/usb/xen-usb.c
+++ b/hw/usb/xen-usb.c
@@ -19,13 +19,10 @@
  *  GNU GPL, version 2 or (at your option) any later version.
  */
 
+#include "qemu/osdep.h"
 #include 
-#include 
-#include 
 #include 
-#include 
 
-#include "qemu/osdep.h"
 #include "qemu-common.h"
 #include "qemu/config-file.h"
 #include "hw/sysbus.h"
diff --git a/include/hw/xen/xen.h b/include/hw/xen/xen.h
index 6365483..b2cd992 100644
--- a/include/hw/xen/xen.h
+++ b/include/hw/xen/xen.h
@@ -8,7 +8,6 @@
  */
 
 #include "qemu-common.h"
-#include "qemu/typedefs.h"
 #include "exec/cpu-common.h"
 #include "hw/irq.h"
 
-- 
1.9.1


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

[Xen-devel] [PULL 1/2] xen/blkif: avoid double access to any shared ring request fields

[Stefano Stabellini]

From: Jan Beulich 

Commit f9e98e5d7a ("xen/blkif: Avoid double access to
src->nr_segments") didn't go far enough: src->operation is also being
used twice. And nothing was done to prevent the compiler from using the
source side of the copy done by blk_get_request() (granted that's very
unlikely).

Move the barrier()s up, and add another one to blk_get_request().

Note that for completing XSA-155, the barrier() getting added to
blk_get_request() would suffice, and hence the changes to xen_blkif.h
are more like just cleanup. And since, as said, the unpatched code
getting compiled to something vulnerable is very unlikely (and not
observed in practice), this isn't being viewed as a new security issue.

Signed-off-by: Jan Beulich 
Reviewed-by: Stefano Stabellini 
Signed-off-by: Stefano Stabellini 
---
 hw/block/xen_blkif.h | 12 ++--
 hw/block/xen_disk.c  |  2 ++
 2 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/hw/block/xen_blkif.h b/hw/block/xen_blkif.h
index c68487cb..e3b133b 100644
--- a/hw/block/xen_blkif.h
+++ b/hw/block/xen_blkif.h
@@ -79,14 +79,14 @@ static inline void blkif_get_x86_32_req(blkif_request_t 
*dst, blkif_x86_32_reque
dst->handle = src->handle;
dst->id = src->id;
dst->sector_number = src->sector_number;
-   if (src->operation == BLKIF_OP_DISCARD) {
+   /* Prevent the compiler from using src->... instead. */
+   barrier();
+   if (dst->operation == BLKIF_OP_DISCARD) {
struct blkif_request_discard *s = (void *)src;
struct blkif_request_discard *d = (void *)dst;
d->nr_sectors = s->nr_sectors;
return;
}
-   /* prevent the compiler from optimizing the code and using 
src->nr_segments instead */
-   barrier();
if (n > dst->nr_segments)
n = dst->nr_segments;
for (i = 0; i < n; i++)
@@ -102,14 +102,14 @@ static inline void blkif_get_x86_64_req(blkif_request_t 
*dst, blkif_x86_64_reque
dst->handle = src->handle;
dst->id = src->id;
dst->sector_number = src->sector_number;
-   if (src->operation == BLKIF_OP_DISCARD) {
+   /* Prevent the compiler from using src->... instead. */
+   barrier();
+   if (dst->operation == BLKIF_OP_DISCARD) {
struct blkif_request_discard *s = (void *)src;
struct blkif_request_discard *d = (void *)dst;
d->nr_sectors = s->nr_sectors;
return;
}
-   /* prevent the compiler from optimizing the code and using 
src->nr_segments instead */
-   barrier();
if (n > dst->nr_segments)
n = dst->nr_segments;
for (i = 0; i < n; i++)
diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
index 064c116..cf57814 100644
--- a/hw/block/xen_disk.c
+++ b/hw/block/xen_disk.c
@@ -679,6 +679,8 @@ static int blk_get_request(struct XenBlkDev *blkdev, struct 
ioreq *ioreq, RING_I
  RING_GET_REQUEST(>rings.x86_64_part, rc));
 break;
 }
+/* Prevent the compiler from accessing the on-ring fields instead. */
+barrier();
 return 0;
 }
 
-- 
1.9.1


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

[Xen-devel] [PULL 0/2] xen-20160614-tag

[Stefano Stabellini]

The following changes since commit 55e5c3a2d2433bd2e1e635a7ba395f1c70341794:

  Merge remote-tracking branch 
'remotes/berrange/tags/qcrypto-next-2016-06-13-v1' into staging (2016-06-13 
13:05:02 +0100)

are available in the git repository at:


  git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-20160614-tag

for you to fetch changes up to b1b23e5bbfb66d9401e2c2b0646fb721d94a3f83:

  xen: Clean up includes (2016-06-14 15:37:43 +0100)


Xen 2016/06/14


Jan Beulich (1):
  xen/blkif: avoid double access to any shared ring request fields

Peter Maydell (1):
  xen: Clean up includes

 hw/block/xen_blkif.h | 12 ++--
 hw/block/xen_disk.c  |  2 ++
 hw/usb/xen-usb.c |  5 +
 include/hw/xen/xen.h |  1 -
 4 files changed, 9 insertions(+), 11 deletions(-)

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

Re: [Xen-devel] [PATCH] x86: show remote CPU state upon fatal NMI

[Andrew Cooper]

On 14/06/16 15:33, Jan Beulich wrote:
> Quite frequently the watchdog would hit an innocent CPU, e.g. one
> trying to acquire a spin lock a remote CPU holds for extended periods
> of time, or a random CPU in TSC calbration rendezvous. In such cases
> the register and stack dump for that CPU doesn't really help in the
> analysis of the problem.
>
> To keep things reasonable on large systems, only log CS:RIP by default.
> This can be overridden via a new extension to the "nmi=" command line
> option such that full register/stack state will get dumped.
>
> Signed-off-by: Jan Beulich 
>
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -1155,7 +1155,7 @@ Use the MWAIT idle driver (with model sp
>  of the ACPI based one.
>  
>  ### nmi
> -> `= ignore | dom0 | fatal`
> +> `= ignore | dom0 | fatal [,show-all]`
>  
>  > Default: `fatal` for a debug build, or `dom0` for a non-debug build
>  
> @@ -1163,6 +1163,9 @@ Specify what Xen should do in the event
>  `ignore` discards the error; `dom0` causes Xen to report the error to
>  dom0, while 'fatal' causes Xen to print diagnostics and then hang.
>  
> +The `show-all` modifier forces all CPUs' full state to be dumped upon
> +fatal NMIs (normally a result of the watchdog kicking in).
> +
>  ### noapic
>  
>  Instruct Xen to ignore any IOAPICs that are present in the system, and
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -84,10 +84,11 @@
>   *  dom0:   The NMI is virtualised to DOM0.
>   *  ignore: The NMI error is cleared and ignored.
>   */
> +static char __read_mostly opt_nmi[16] =
>  #ifdef NDEBUG
> -static char __read_mostly opt_nmi[10] = "dom0";
> + "dom0";
>  #else
> -static char __read_mostly opt_nmi[10] = "fatal";
> + "fatal";
>  #endif
>  string_param("nmi", opt_nmi);
>  
> @@ -525,6 +526,35 @@ void vcpu_show_execution_state(struct vc
>  vcpu_unpause(v);
>  }
>  
> +static cpumask_t nmi_show_state_mask;
> +static bool_t opt_nmi_show_all;
> +
> +static int __init get_nmi_show_all(void)
> +{
> +const char *s = strchr(opt_nmi, ',');
> +
> +if ( s && !strcmp(s + 1, "show-all") )
> +opt_nmi_show_all = 1;
> +
> +return 0;
> +}
> +presmp_initcall(get_nmi_show_all);
> +
> +static int nmi_show_execution_state(const struct cpu_user_regs *regs, int 
> cpu)
> +{
> +if ( !cpumask_test_cpu(cpu, _show_state_mask) )
> +return 0;
> +
> +if ( opt_nmi_show_all )
> +show_execution_state(regs);
> +else
> +printk(XENLOG_ERR "CPU%d @ %04x:%08lx (%pS)\n", cpu, regs->cs, 
> regs->rip,
> +   guest_mode(regs) ? _p(regs->rip) : NULL);
> +cpumask_clear_cpu(cpu, _show_state_mask);

I would clear the mask before printing state.  Given the nature of this
handler, it liable to contend sufficiently on the console lock to induce
the further watchdog timeout.

> +
> +return 1;
> +}
> +
>  static const char *trapstr(unsigned int trapnr)
>  {
>  static const char * const strings[] = {
> @@ -570,6 +600,15 @@ void fatal_trap(const struct cpu_user_re
>  printk("Faulting linear address: %p\n", _p(cr2));
>  show_page_walk(cr2);
>  }
> +else if ( trapnr == TRAP_nmi )
> +{
> +cpumask_andnot(_show_state_mask, _online_map,
> +   cpumask_of(smp_processor_id()));
> +set_nmi_callback(nmi_show_execution_state);
> +smp_send_nmi_allbutself();

This would cause far less spinlock contention as

for_each_cpu( cpu, nmi_show_state_mask )
smp_send_nmi(cpu);

I realise this involves introducing a new smp function, but it would
substantially reduce contention on the console lock.


I would recommend moving this clause into nmi_watchdog_tick(), so that
it doesn't get involved for non-watchdog NMIs.  IOCK/SERR NMIs won't
have anything interesting to print from here.  I would also recommend
disabling the watchdog before IPI'ing.

~Andrew

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

Re: [Xen-devel] Question of xl dump-core

[Konrad Rzeszutek Wilk]

On Tue, Jun 14, 2016 at 08:21:16AM +0800, wj zhou wrote:
> Hello all,

Hey,

CC-ing Daniel, and Dave.
> 
> Sorry to disturb you, but I really want to figure it out.
> The xen core of redhat 6 with pod is unable to be used with crash.
> 
> I installed a hvm of redhat 6 by xen 4.7.0-rc2.
> And the memory is set as below:
> memory=1024
> maxmem=4096
> 
> "xl dump-core" is executed, and the core is produced successfully.
> I got the following message:
> xc: info: exceeded nr_pages (26) losing pages
> 
> Unfortunately, I got some errors when executing crash with it.
> The below is the log of crash.
> 
> 
> crash 7.0.9-4.el7

http://people.redhat.com/anderson says that the latest is 7.1.5.
Can you try that version?

> ...
> 
> please wait... (gathering kmem slab cache data)
> crash: read error: kernel virtual address: 88010b532e00  type:
> "kmem_cache buffer"
> 
> crash: unable to initialize kmem slab cache subsystem
> 
> please wait... (gathering module symbol data)
> crash: read error: physical address: 1058a1000  type: "page table"
> 
> 
> I knew balloon is not supported by redhat 6, so pod is also not supported.

?

> But I wonder the reason why the above error happens.
> Balloon and pod are also not supported by redhat 7, but it won't
> happen in redhat 7 hvm.
> I'm very appreciated if someone can help me.

Well, does it work if you maxmem != memory ?

> 
> -- 
> Regards
> Zhou
> 
> ___
> 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 V9 2/3] drivers/pl011: Use combination of UARTRIS and UARTMSC instead of UARTMIS

[Julien Grall]

Hello Shanker,

On 13/06/16 18:43, Shanker Donthineni wrote:



On 06/13/2016 05:30 AM, Stefano Stabellini wrote:

On Thu, 9 Jun 2016, Shanker Donthineni wrote:

The Masked interrupt status register (UARTMIS) is not described in ARM
SBSA 2.x document. Anding of two registers UARTMSC and UARTRIS values
gives the same information as register UARTMIS.

UARTRIS, UARTMSC and UARTMIS definitions are found in PrimeCell UART
PL011 (Revision: r1p4).
  - 3.3.10 Interrupt mask set/clear register, UARTIMSC
  - 3.3.11 Raw interrupt status register, UARTRIS
  - 3.3.12 Masked interrupt status register, UARTMIS

This change is necessary for driver to be SBSA compliant v2.x without
affecting the current driver functionality.

Signed-off-by: Shanker Donthineni 
Reviewed-by: Julien Grall 

Changes since v8:
  Fixed white spaces.

Changes since v7:
  Moved comment 'To compatible with SBSA v2.x document, all accesses

should be 32-bit' to #3

Changes since v1:
  Added a new function to return an interrupt status.

  xen/drivers/char/pl011.c | 10 --
  1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/xen/drivers/char/pl011.c b/xen/drivers/char/pl011.c
index 6a3c21b..7e19c4a 100644
--- a/xen/drivers/char/pl011.c
+++ b/xen/drivers/char/pl011.c
@@ -53,11 +53,17 @@ static struct pl011 {
  #define pl011_read(uart, off)   readl((uart)->regs + (off))
  #define pl011_write(uart, off,val)  writel((val), (uart)->regs +

(off))

+static unsigned int pl011_intr_status(struct pl011 *uart)

Maybe this should be static inline?

In any case the series is good, I am happy to queue it up for 4.8.

Nice discussion on usage of keyword 'inline',
https://www.kernel.org/doc/local/inline.html.


Well, this page has been created in 2007. GCC may have been fixed since 
then.


Looking at the GCC manual [1]: "GCC does not inline any functions when 
not optimizing unless you specify the ‘always_inline’ attribute for the 
function". Although, non-debug build will always have use optimization 
flags. For debug build, we don't really care about performance so this 
is fine.


Note that without the keyword "inline" GCC may or not may inline the 
function. In the case of this patch, this would result to 2 function 
calls in the interrupt handler. Also, Xen may be built by other 
compilers than GCC (such as Clang) which may require the keyword 
"inline" to effectively inline the function.


Anyway, as mentioned by Stefano this is not that important.

Regards,

[1] https://gcc.gnu.org/onlinedocs/gcc/Inline.html#Inline

--
Julien Grall

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

[Xen-devel] [PATCH] x86/HVM: rename mmio_gva field to mmio_gla

[Jan Beulich]

... to correctly reflect its purpose. To make things consistent also
rename handle_mmio_with_translation()'s respective parameter (but don't
touch sh_page_fault(), as renaming its parameter would require quite a
few more changes there).

Suggested-by: Andrew Cooper 
Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -684,7 +684,7 @@ static void latch_linear_to_phys(struct
 if ( vio->mmio_access.gla_valid )
 return;
 
-vio->mmio_gva = gla & PAGE_MASK;
+vio->mmio_gla = gla & PAGE_MASK;
 vio->mmio_gpfn = PFN_DOWN(gpa);
 vio->mmio_access = (struct npfec){ .gla_valid = 1,
.read_access = 1,
@@ -782,7 +782,7 @@ static int __hvmemul_read(
 if ( ((access_type != hvm_access_insn_fetch
? vio->mmio_access.read_access
: vio->mmio_access.insn_fetch)) &&
- (vio->mmio_gva == (addr & PAGE_MASK)) )
+ (vio->mmio_gla == (addr & PAGE_MASK)) )
 return hvmemul_linear_mmio_read(addr, bytes, p_data, pfec, 
hvmemul_ctxt, 1);
 
 if ( (seg != x86_seg_none) &&
@@ -889,7 +889,7 @@ static int hvmemul_write(
 return rc;
 
 if ( vio->mmio_access.write_access &&
- (vio->mmio_gva == (addr & PAGE_MASK)) )
+ (vio->mmio_gla == (addr & PAGE_MASK)) )
 return hvmemul_linear_mmio_write(addr, bytes, p_data, pfec, 
hvmemul_ctxt, 1);
 
 if ( (seg != x86_seg_none) &&
@@ -1181,7 +1181,7 @@ static int hvmemul_rep_movs(
 
 bytes = PAGE_SIZE - (saddr & ~PAGE_MASK);
 if ( vio->mmio_access.read_access &&
- (vio->mmio_gva == (saddr & PAGE_MASK)) &&
+ (vio->mmio_gla == (saddr & PAGE_MASK)) &&
  bytes >= bytes_per_rep )
 {
 sgpa = pfn_to_paddr(vio->mmio_gpfn) | (saddr & ~PAGE_MASK);
@@ -1200,7 +1200,7 @@ static int hvmemul_rep_movs(
 
 bytes = PAGE_SIZE - (daddr & ~PAGE_MASK);
 if ( vio->mmio_access.write_access &&
- (vio->mmio_gva == (daddr & PAGE_MASK)) &&
+ (vio->mmio_gla == (daddr & PAGE_MASK)) &&
  bytes >= bytes_per_rep )
 {
 dgpa = pfn_to_paddr(vio->mmio_gpfn) | (daddr & ~PAGE_MASK);
@@ -1320,7 +1320,7 @@ static int hvmemul_rep_stos(
 
 bytes = PAGE_SIZE - (addr & ~PAGE_MASK);
 if ( vio->mmio_access.write_access &&
- (vio->mmio_gva == (addr & PAGE_MASK)) &&
+ (vio->mmio_gla == (addr & PAGE_MASK)) &&
  bytes >= bytes_per_rep )
 {
 gpa = pfn_to_paddr(vio->mmio_gpfn) | (addr & ~PAGE_MASK);
--- a/xen/arch/x86/hvm/io.c
+++ b/xen/arch/x86/hvm/io.c
@@ -114,7 +114,7 @@ int handle_mmio(void)
 return 1;
 }
 
-int handle_mmio_with_translation(unsigned long gva, unsigned long gpfn,
+int handle_mmio_with_translation(unsigned long gla, unsigned long gpfn,
  struct npfec access)
 {
 struct hvm_vcpu_io *vio = >arch.hvm_vcpu.hvm_io;
@@ -122,7 +122,7 @@ int handle_mmio_with_translation(unsigne
 vio->mmio_access = access.gla_valid &&
access.kind == npfec_kind_with_gla
? access : (struct npfec){};
-vio->mmio_gva = gva & PAGE_MASK;
+vio->mmio_gla = gla & PAGE_MASK;
 vio->mmio_gpfn = gpfn;
 return handle_mmio();
 }
--- a/xen/include/asm-x86/hvm/io.h
+++ b/xen/include/asm-x86/hvm/io.h
@@ -119,7 +119,7 @@ void relocate_portio_handler(
 void send_timeoffset_req(unsigned long timeoff);
 void send_invalidate_req(void);
 int handle_mmio(void);
-int handle_mmio_with_translation(unsigned long gva, unsigned long gpfn,
+int handle_mmio_with_translation(unsigned long gla, unsigned long gpfn,
  struct npfec);
 int handle_pio(uint16_t port, unsigned int size, int dir);
 void hvm_interrupt_post(struct vcpu *v, int vector, int type);
--- a/xen/include/asm-x86/hvm/vcpu.h
+++ b/xen/include/asm-x86/hvm/vcpu.h
@@ -60,12 +60,12 @@ struct hvm_vcpu_io {
 
 /*
  * HVM emulation:
- *  Virtual address @mmio_gva maps to MMIO physical frame @mmio_gpfn.
+ *  Linear address @mmio_gla maps to MMIO physical frame @mmio_gpfn.
  *  The latter is known to be an MMIO frame (not RAM).
  *  This translation is only valid for accesses as per @mmio_access.
  */
 struct npfecmmio_access;
-unsigned long   mmio_gva;
+unsigned long   mmio_gla;
 unsigned long   mmio_gpfn;
 
 /*


x86/HVM: rename mmio_gva field to mmio_gla

... to correctly reflect its purpose. To make things consistent also
rename handle_mmio_with_translation()'s respective parameter (but don't
touch sh_page_fault(), as renaming its parameter would require quite a
few more changes there).

Suggested-by: Andrew Cooper 
Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -684,7 +684,7 @@ static void latch_linear_to_phys(struct
 if ( vio->mmio_access.gla_valid )
 

Re: [Xen-devel] [PATCH] x86/HVM: rename mmio_gva field to mmio_gla

[Andrew Cooper]

On 14/06/16 15:44, Jan Beulich wrote:
> ... to correctly reflect its purpose. To make things consistent also
> rename handle_mmio_with_translation()'s respective parameter (but don't
> touch sh_page_fault(), as renaming its parameter would require quite a
> few more changes there).
>
> Suggested-by: Andrew Cooper 
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH] xen: move xen_sysdev to xen_backend.c

[Anthony PERARD]

On Mon, Jun 13, 2016 at 11:12:21AM +0200, Juergen Gross wrote:
> Commit 9432e53a5bc88681b2d3aec4dac9db07c5476d1b added xen_sysdev as a
> system device to serve as an anchor for removable virtual buses. This
> introduced a build failure for non-x86 builds with CONFIG_XEN_BACKEND
> set, as xen_sysdev was defined in a x86 specific file while being
> consumed in an architecture independent source.
> 
> Move the xen_sysdev definition and initialization to xen_backend.c to
> avoid the build failure.
> 
> Signed-off-by: Juergen Gross 

Reviewed-by: Anthony PERARD 

-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH] xen: Clean up includes

[Peter Maydell]

On 14 June 2016 at 15:37, Stefano Stabellini  wrote:
> I didn't lose it, I thought you had already committed it as
> 21cbfe5f37aaa3a13d3af28454e762c05be67429, but I realize now that
> although they have the same commit message, they are not the same patch.
>
> I was wondering how it got upstream given that I didn't send a pull
> request for it. Mystery solved. Next time it might be good to avoid
> having multiple patches touching similar code with exactly the same
> commit description.

Mmm, unfortunate side effect of the commit message being automatically
created by the clean-includes script.

-- PMM

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

Re: [Xen-devel] [PATCH raisin 4/4] Update to 4.7, update qemu and qemu_traditional recipes

[George Dunlap]

On 14/06/16 15:23, Anthony PERARD wrote:
> On Tue, Jun 14, 2016 at 03:00:12PM +0100, George Dunlap wrote:
>> On 14/06/16 14:53, Anthony PERARD wrote:
>>> On Tue, Jun 14, 2016 at 11:34:43AM +0100, George Dunlap wrote:
 That code might be in qemu-upstream, but it's not in the qemu-xen trees;
 if you revert this bit of the patch and try to build with raisin it will
 fail.  That's why I even bothered to add these in in the first place;
 and why IanC added these runes to tools/Makefile.

 Anthony, can you comment more authoritatively here on what's going on?
>>>
>>> Yes, easy, xen-4.7 introduce a new API but qemu-xen-4.7 does not know
>>> about it, so qemu-xen will fail to compile. But there are some magic
>>> flags that are use to provide an compatible API and can qemu-xen
>>> compile.
>>>
>>> QEMU have been taught about the new API and will use it, without the
>>> magic flags. QEMU will actually ignore the magic flags with a bunch of
>>> #undef.
>>
>> So wait, I'm confused.  Isn't qemu-xen supposed to be upstream qemu plus
>> a handful of patches on top?  Or has there not been a QEMU release since
>> the time the new API?
> 
> The first release to include the new stuff appear to be 2.6, which have
> been released a month ago. So the answer is no.

OK, but presumably you'll pull in / rebase qemu-unstable at some point
in the next few weeks and then we can take the magic runes out of
tools/Makefile.

So back to raisin: I'll make a conditional to only add this for 4.7,
with an explanation; and when it gets fixed for 4.7.1 I'll take it out.

Thanks.
 -George

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

[Xen-devel] [PATCH] x86: show remote CPU state upon fatal NMI

[Jan Beulich]

Quite frequently the watchdog would hit an innocent CPU, e.g. one
trying to acquire a spin lock a remote CPU holds for extended periods
of time, or a random CPU in TSC calbration rendezvous. In such cases
the register and stack dump for that CPU doesn't really help in the
analysis of the problem.

To keep things reasonable on large systems, only log CS:RIP by default.
This can be overridden via a new extension to the "nmi=" command line
option such that full register/stack state will get dumped.

Signed-off-by: Jan Beulich 

--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1155,7 +1155,7 @@ Use the MWAIT idle driver (with model sp
 of the ACPI based one.
 
 ### nmi
-> `= ignore | dom0 | fatal`
+> `= ignore | dom0 | fatal [,show-all]`
 
 > Default: `fatal` for a debug build, or `dom0` for a non-debug build
 
@@ -1163,6 +1163,9 @@ Specify what Xen should do in the event
 `ignore` discards the error; `dom0` causes Xen to report the error to
 dom0, while 'fatal' causes Xen to print diagnostics and then hang.
 
+The `show-all` modifier forces all CPUs' full state to be dumped upon
+fatal NMIs (normally a result of the watchdog kicking in).
+
 ### noapic
 
 Instruct Xen to ignore any IOAPICs that are present in the system, and
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -84,10 +84,11 @@
  *  dom0:   The NMI is virtualised to DOM0.
  *  ignore: The NMI error is cleared and ignored.
  */
+static char __read_mostly opt_nmi[16] =
 #ifdef NDEBUG
-static char __read_mostly opt_nmi[10] = "dom0";
+ "dom0";
 #else
-static char __read_mostly opt_nmi[10] = "fatal";
+ "fatal";
 #endif
 string_param("nmi", opt_nmi);
 
@@ -525,6 +526,35 @@ void vcpu_show_execution_state(struct vc
 vcpu_unpause(v);
 }
 
+static cpumask_t nmi_show_state_mask;
+static bool_t opt_nmi_show_all;
+
+static int __init get_nmi_show_all(void)
+{
+const char *s = strchr(opt_nmi, ',');
+
+if ( s && !strcmp(s + 1, "show-all") )
+opt_nmi_show_all = 1;
+
+return 0;
+}
+presmp_initcall(get_nmi_show_all);
+
+static int nmi_show_execution_state(const struct cpu_user_regs *regs, int cpu)
+{
+if ( !cpumask_test_cpu(cpu, _show_state_mask) )
+return 0;
+
+if ( opt_nmi_show_all )
+show_execution_state(regs);
+else
+printk(XENLOG_ERR "CPU%d @ %04x:%08lx (%pS)\n", cpu, regs->cs, 
regs->rip,
+   guest_mode(regs) ? _p(regs->rip) : NULL);
+cpumask_clear_cpu(cpu, _show_state_mask);
+
+return 1;
+}
+
 static const char *trapstr(unsigned int trapnr)
 {
 static const char * const strings[] = {
@@ -570,6 +600,15 @@ void fatal_trap(const struct cpu_user_re
 printk("Faulting linear address: %p\n", _p(cr2));
 show_page_walk(cr2);
 }
+else if ( trapnr == TRAP_nmi )
+{
+cpumask_andnot(_show_state_mask, _online_map,
+   cpumask_of(smp_processor_id()));
+set_nmi_callback(nmi_show_execution_state);
+smp_send_nmi_allbutself();
+while ( !cpumask_empty(_show_state_mask) )
+cpu_relax();
+}
 }
 
 panic("FATAL TRAP: vector = %d (%s)\n"



x86: show remote CPU state upon fatal NMI

Quite frequently the watchdog would hit an innocent CPU, e.g. one
trying to acquire a spin lock a remote CPU holds for extended periods
of time, or a random CPU in TSC calbration rendezvous. In such cases
the register and stack dump for that CPU doesn't really help in the
analysis of the problem.

To keep things reasonable on large systems, only log CS:RIP by default.
This can be overridden via a new extension to the "nmi=" command line
option such that full register/stack state will get dumped.

Signed-off-by: Jan Beulich 

--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1155,7 +1155,7 @@ Use the MWAIT idle driver (with model sp
 of the ACPI based one.
 
 ### nmi
-> `= ignore | dom0 | fatal`
+> `= ignore | dom0 | fatal [,show-all]`
 
 > Default: `fatal` for a debug build, or `dom0` for a non-debug build
 
@@ -1163,6 +1163,9 @@ Specify what Xen should do in the event
 `ignore` discards the error; `dom0` causes Xen to report the error to
 dom0, while 'fatal' causes Xen to print diagnostics and then hang.
 
+The `show-all` modifier forces all CPUs' full state to be dumped upon
+fatal NMIs (normally a result of the watchdog kicking in).
+
 ### noapic
 
 Instruct Xen to ignore any IOAPICs that are present in the system, and
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -84,10 +84,11 @@
  *  dom0:   The NMI is virtualised to DOM0.
  *  ignore: The NMI error is cleared and ignored.
  */
+static char __read_mostly opt_nmi[16] =
 #ifdef NDEBUG
-static char __read_mostly opt_nmi[10] = "dom0";
+ "dom0";
 #else
-static char __read_mostly opt_nmi[10] = "fatal";
+ "fatal";
 #endif
 string_param("nmi", opt_nmi);
 
@@ -525,6 +526,35 @@ void 

Re: [Xen-devel] [PATCH] xen: Clean up includes

[Stefano Stabellini]

On Tue, 14 Jun 2016, Peter Maydell wrote:
> On 30 May 2016 at 16:54, Stefano Stabellini  wrote:
> > On Tue, 24 May 2016, Peter Maydell wrote:
> >> Clean up includes so that osdep.h is included first and headers
> >> which it implies are not included manually.
> >>
> >> This commit was created with scripts/clean-includes.
> >>
> >> Signed-off-by: Peter Maydell 
> >
> > Reviewed-by: Stefano Stabellini 
> >
> > Added to my queue
> 
> Hi; did this patch get lost? You've done a xen pullreq since
> this but this patch wasn't in it.

I didn't lose it, I thought you had already committed it as
21cbfe5f37aaa3a13d3af28454e762c05be67429, but I realize now that
although they have the same commit message, they are not the same patch.

I was wondering how it got upstream given that I didn't send a pull
request for it. Mystery solved. Next time it might be good to avoid
having multiple patches touching similar code with exactly the same
commit description.

I'll send another pull request today.

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

Re: [Xen-devel] [PATCH raisin 4/4] Update to 4.7, update qemu and qemu_traditional recipes

[Anthony PERARD]

On Tue, Jun 14, 2016 at 03:00:12PM +0100, George Dunlap wrote:
> On 14/06/16 14:53, Anthony PERARD wrote:
> > On Tue, Jun 14, 2016 at 11:34:43AM +0100, George Dunlap wrote:
> >> That code might be in qemu-upstream, but it's not in the qemu-xen trees;
> >> if you revert this bit of the patch and try to build with raisin it will
> >> fail.  That's why I even bothered to add these in in the first place;
> >> and why IanC added these runes to tools/Makefile.
> >>
> >> Anthony, can you comment more authoritatively here on what's going on?
> > 
> > Yes, easy, xen-4.7 introduce a new API but qemu-xen-4.7 does not know
> > about it, so qemu-xen will fail to compile. But there are some magic
> > flags that are use to provide an compatible API and can qemu-xen
> > compile.
> > 
> > QEMU have been taught about the new API and will use it, without the
> > magic flags. QEMU will actually ignore the magic flags with a bunch of
> > #undef.
> 
> So wait, I'm confused.  Isn't qemu-xen supposed to be upstream qemu plus
> a handful of patches on top?  Or has there not been a QEMU release since
> the time the new API?

The first release to include the new stuff appear to be 2.6, which have
been released a month ago. So the answer is no.

> Why on earth are we shipping in 4.7 a qemu that
> can't use the new API we define in 4.7?

Who knows...

> >> Would it be possible for 4.7.1 to backport the configure auto-detection
> >> stuff?
> > 
> > I think that would be possible. But backporting the use of the new api
> > will probably be harder. I guess we could just have qemu-xen define the
> > magic flags itself instead of relying on them been given via a configure
> > option.
> 
> Well at this point it's a bit late to import support for the new API
> into qemu-xen-4.7; but it would be good for 4.7.1 to have qemu-xen's
> configure set the necessary flags rather than bodging them in via
> "--extra-cflags" in the Xen makefile.

Yes.

-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH] libxl: correct xl cpupool-numa-split with vcpu limited dom0

[Ian Jackson]

Juergen Gross writes ("Re: [Xen-devel] [PATCH] libxl: correct xl 
cpupool-numa-split with vcpu limited dom0"):
> On 14/06/16 12:07, Ian Jackson wrote:
> > I looked at the code for a minute or two, and perhaps I'm being dense
> > this morning, but I wasn't able to see (from the code and the commit
> > message and from the diff) precisely what misunderstanding the
> > original author of the code had, and how this patch fixes it.
> 
> The problem arises if dom0 has less vcpus than a numa node. In this case
> libxl_set_vcpuonline() will fail as the cpumap has more bits set than
> the number of dom0's vcpus.

Oh, right, of course.

> My patch will result in a call of libxl_set_vcpuonline() only in case
> dom0 has more vcpus online than the number of cpus of node it is to be
> restricted to.

That makes sense, thanks.

I have made a note of this patch in my backport list.

Ian.

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

Re: [Xen-devel] [PATCH 1/6] xl: remus/colo: only initialise ha variable when necessary

[Wei Liu]

On Tue, Jun 14, 2016 at 03:15:19PM +0100, Ian Jackson wrote:
> Wei Liu writes ("Re: [PATCH 1/6] xl: remus/colo: only initialise ha variable 
> when necessary"):
> > On Tue, Jun 14, 2016 at 11:18:16AM +0100, Ian Jackson wrote:
> > > Wei Liu writes ("[PATCH 1/6] xl: remus/colo: only initialise ha variable 
> > > when necessary"):
> > > > The original code is bogus because the common case is no HA enabled.
> > > > Setting ha variable at the beginning is not very useful.
> > > 
> > > This seems like a plausible cleanup but I don't understand why you say
> > > the original code is `bogus'.  Is it wrong ?  If so you don't say how.
> > 
> > What I meant is "the default state should be no HA enabled", hence if we
> > don't move the ha variable into a narrower scope it should have been
> > initialised to NULL first.  It is not a bug though.
> 
> IC.  Perhaps you'd like to clarify the commit message ?

Sure, I will incorporate my reply above to the commit message.

> Whether or not you do,
> 
> Acked-by: Ian Jackson 

Thanks.

Wei.

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

Re: [Xen-devel] [PATCH 1/6] xl: remus/colo: only initialise ha variable when necessary

[Ian Jackson]

Wei Liu writes ("Re: [PATCH 1/6] xl: remus/colo: only initialise ha variable 
when necessary"):
> On Tue, Jun 14, 2016 at 11:18:16AM +0100, Ian Jackson wrote:
> > Wei Liu writes ("[PATCH 1/6] xl: remus/colo: only initialise ha variable 
> > when necessary"):
> > > The original code is bogus because the common case is no HA enabled.
> > > Setting ha variable at the beginning is not very useful.
> > 
> > This seems like a plausible cleanup but I don't understand why you say
> > the original code is `bogus'.  Is it wrong ?  If so you don't say how.
> 
> What I meant is "the default state should be no HA enabled", hence if we
> don't move the ha variable into a narrower scope it should have been
> initialised to NULL first.  It is not a bug though.

IC.  Perhaps you'd like to clarify the commit message ?
Whether or not you do,

Acked-by: Ian Jackson 

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail 
REGR. vs. 94856
 test-amd64-i386-freebsd10-amd64 10 guest-startfail REGR. vs. 94856
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 15 guest-localmigrate/x10 fail REGR. 
vs. 94856
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1fail REGR. vs. 94856
 test-amd64-amd64-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail REGR. vs. 
94856

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-localmigrate fail in 95573 pass in 
95649
 test-armhf-armhf-xl-credit2   6 xen-boot   fail in 95573 pass in 95649
 test-amd64-i386-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail pass in 95573

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-localmigrate fail REGR. vs. 94856
 test-amd64-i386-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-qemuu-nested-intel 14 capture-logs/l1(14) fail in 95573 
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-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-xsm 12 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-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   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  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   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-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   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-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-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-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 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

version targeted for testing:
 qemuua93c1bdf0bd4689287094ddb2aae3dc907da3535
baseline version:
 qemuud6550e9ed2e1a60d889dfb721de00d9a4e3bafbe

Last test of basis94856  2016-05-27 20:14:49 Z   17 days
Failing since 94983  2016-05-31 09:40:12 Z   14 days   18 attempts
Testing same since95573  2016-06-11 22:06:58 Z2 days2 attempts


People who touched revisions under test:
  Alberto Garcia 
  Alex Bennée 
  Alexander Graf 
  Alexey Kardashevskiy 
  Alistair Francis 
  Anthony PERARD 
  Ard Biesheuvel 
  Benjamin Herrenschmidt 
  Bharata B Rao 
  Cao jin 

Re: [Xen-devel] [PATCH] xen: Clean up includes

[Peter Maydell]

On 30 May 2016 at 16:54, Stefano Stabellini  wrote:
> On Tue, 24 May 2016, Peter Maydell wrote:
>> Clean up includes so that osdep.h is included first and headers
>> which it implies are not included manually.
>>
>> This commit was created with scripts/clean-includes.
>>
>> Signed-off-by: Peter Maydell 
>
> Reviewed-by: Stefano Stabellini 
>
> Added to my queue

Hi; did this patch get lost? You've done a xen pullreq since
this but this patch wasn't in it.

thanks
-- PMM

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

Re: [Xen-devel] [PATCH raisin 4/4] Update to 4.7, update qemu and qemu_traditional recipes

[George Dunlap]

On 14/06/16 14:53, Anthony PERARD wrote:
> On Tue, Jun 14, 2016 at 11:34:43AM +0100, George Dunlap wrote:
>> On 14/06/16 11:31, Stefano Stabellini wrote:
>>> On Tue, 14 Jun 2016, George Dunlap wrote:
 On 14/06/16 11:08, Stefano Stabellini wrote:
> On Tue, 14 Jun 2016, George Dunlap wrote:
>> On 14/06/16 10:46, Stefano Stabellini wrote:
>>> On Mon, 13 Jun 2016, George Dunlap wrote:
 Add a 4.7 config file, make it the default.

 Also update the qemu and qemu_traditional recipies after Ian Cambell's
 work to split off separate libraries.

 Signed-off-by: George Dunlap 
 ---
 CC: Stefano Stabellini 
 ---
  components/qemu | 21 +
  components/qemu_traditional |  2 +-
  configs/config-4.7  |  8 
  defconfig   |  2 +-
  4 files changed, 23 insertions(+), 10 deletions(-)

 diff --git a/components/qemu b/components/qemu
 index e0d92a5..8624b50 100644
 --- a/components/qemu
 +++ b/components/qemu
 @@ -23,15 +23,20 @@ function qemu_build() {
  cd "$BASEDIR"
  git-checkout $QEMU_URL $QEMU_REVISION qemu-dir
  cd qemu-dir
 -./configure --enable-xen --target-list=i386-softmmu 
 --prefix=$PREFIX \
 ---extra-cflags="-I$INST_DIR/$PREFIX/include" \
 ---extra-ldflags="-L$INST_DIR/$PREFIX/lib 
 -Wl,-rpath-link=$INST_DIR/$PREFIX/lib \
 +
 +./configure --enable-xen --target-list=i386-softmmu \
 +  --prefix=$PREFIX \
 +  --extra-cflags="-DXC_WANT_COMPAT_EVTCHN_API=1 \
 +  -DXC_WANT_COMPAT_GNTTAB_API=1 \
 +  -DXC_WANT_COMPAT_MAP_FOREIGN_API=1 \
 +-I$INST_DIR/$PREFIX/include" \
 +  --extra-ldflags="-L$INST_DIR/$PREFIX/lib 
 -Wl,-rpath-link=$INST_DIR/$PREFIX/lib \
   -L$INST_DIR/$PREFIX/lib64 
 -Wl,-rpath-link=$INST_DIR/$PREFIX/lib64" \
 ---disable-kvm \
 ---disable-docs \
 ---bindir=$PREFIX/lib/xen/bin \
 ---datadir=$PREFIX/share/qemu-xen \
 ---disable-guest-agent
 +  --bindir=$PREFIX/lib/xen/bin \
 +  --datadir=$PREFIX/share/qemu-xen \
 +  --disable-kvm \
 +  --disable-docs \
 +  --disable-guest-agent
>>>
>>> This is adding XC_WANT_COMPAT_EVTCHN_API=1, etc, unconditionally. If we
>>> make this change, will raisin still be able to buil an older qemu
>>> against an older xen?
>>
>> I've tested this with XEN_RELEASE set to 4.5 and 4.6, and it builds just
>> fine.  The #define is just ignored, since neither Xen nor qemu in the
>> 4.5 and 4.6 branches know anything about it.
>>
>> If part of our goal is to be a repository of the canonical way to build
>> things, though, perhaps it would be better to have the extra flags be
>> conditional on the value of XEN_RELEASE.
>
> If we are sure that it's ignored than it might be benign. Maybe we
> should just add an in-code comment to explain why we added it though.

 Well really, I think that the detection should be put into the qemu
 configure scripts -- i.e., it should detect that there's the new API and
 add the appropriate #defines itself.  But that's the sort of change I
 don't think there will be a lot of enthusiasm for. :-)
>>>
>>> Actually there is already code in QEMU configure script for the
>>> detection. In fact I was wondering if explicitly passing XC_WANT_* is
>>> actually necessary. I don't think it is from QEMU POV.
>>
>> That code might be in qemu-upstream, but it's not in the qemu-xen trees;
>> if you revert this bit of the patch and try to build with raisin it will
>> fail.  That's why I even bothered to add these in in the first place;
>> and why IanC added these runes to tools/Makefile.
>>
>> Anthony, can you comment more authoritatively here on what's going on?
> 
> Yes, easy, xen-4.7 introduce a new API but qemu-xen-4.7 does not know
> about it, so qemu-xen will fail to compile. But there are some magic
> flags that are use to provide an compatible API and can qemu-xen
> compile.
> 
> QEMU have been taught about the new API and will use it, without the
> magic flags. QEMU will actually ignore the magic flags with a bunch of
> #undef.

So wait, I'm confused.  Isn't qemu-xen supposed to be upstream qemu plus
a handful of patches on top?  Or has there not been a QEMU release since
the time the new API?  Why on earth are we shipping in 4.7 a qemu that
can't use the new API we define in 4.7?

>> Would it be possible for 4.7.1 to backport the configure 

Re: [Xen-devel] [PATCH raisin 4/4] Update to 4.7, update qemu and qemu_traditional recipes

[Anthony PERARD]

On Tue, Jun 14, 2016 at 11:34:43AM +0100, George Dunlap wrote:
> On 14/06/16 11:31, Stefano Stabellini wrote:
> > On Tue, 14 Jun 2016, George Dunlap wrote:
> >> On 14/06/16 11:08, Stefano Stabellini wrote:
> >>> On Tue, 14 Jun 2016, George Dunlap wrote:
>  On 14/06/16 10:46, Stefano Stabellini wrote:
> > On Mon, 13 Jun 2016, George Dunlap wrote:
> >> Add a 4.7 config file, make it the default.
> >>
> >> Also update the qemu and qemu_traditional recipies after Ian Cambell's
> >> work to split off separate libraries.
> >>
> >> Signed-off-by: George Dunlap 
> >> ---
> >> CC: Stefano Stabellini 
> >> ---
> >>  components/qemu | 21 +
> >>  components/qemu_traditional |  2 +-
> >>  configs/config-4.7  |  8 
> >>  defconfig   |  2 +-
> >>  4 files changed, 23 insertions(+), 10 deletions(-)
> >>
> >> diff --git a/components/qemu b/components/qemu
> >> index e0d92a5..8624b50 100644
> >> --- a/components/qemu
> >> +++ b/components/qemu
> >> @@ -23,15 +23,20 @@ function qemu_build() {
> >>  cd "$BASEDIR"
> >>  git-checkout $QEMU_URL $QEMU_REVISION qemu-dir
> >>  cd qemu-dir
> >> -./configure --enable-xen --target-list=i386-softmmu 
> >> --prefix=$PREFIX \
> >> ---extra-cflags="-I$INST_DIR/$PREFIX/include" \
> >> ---extra-ldflags="-L$INST_DIR/$PREFIX/lib 
> >> -Wl,-rpath-link=$INST_DIR/$PREFIX/lib \
> >> +
> >> +./configure --enable-xen --target-list=i386-softmmu \
> >> +  --prefix=$PREFIX \
> >> +  --extra-cflags="-DXC_WANT_COMPAT_EVTCHN_API=1 \
> >> +  -DXC_WANT_COMPAT_GNTTAB_API=1 \
> >> +  -DXC_WANT_COMPAT_MAP_FOREIGN_API=1 \
> >> +-I$INST_DIR/$PREFIX/include" \
> >> +  --extra-ldflags="-L$INST_DIR/$PREFIX/lib 
> >> -Wl,-rpath-link=$INST_DIR/$PREFIX/lib \
> >>   -L$INST_DIR/$PREFIX/lib64 
> >> -Wl,-rpath-link=$INST_DIR/$PREFIX/lib64" \
> >> ---disable-kvm \
> >> ---disable-docs \
> >> ---bindir=$PREFIX/lib/xen/bin \
> >> ---datadir=$PREFIX/share/qemu-xen \
> >> ---disable-guest-agent
> >> +  --bindir=$PREFIX/lib/xen/bin \
> >> +  --datadir=$PREFIX/share/qemu-xen \
> >> +  --disable-kvm \
> >> +  --disable-docs \
> >> +  --disable-guest-agent
> >
> > This is adding XC_WANT_COMPAT_EVTCHN_API=1, etc, unconditionally. If we
> > make this change, will raisin still be able to buil an older qemu
> > against an older xen?
> 
>  I've tested this with XEN_RELEASE set to 4.5 and 4.6, and it builds just
>  fine.  The #define is just ignored, since neither Xen nor qemu in the
>  4.5 and 4.6 branches know anything about it.
> 
>  If part of our goal is to be a repository of the canonical way to build
>  things, though, perhaps it would be better to have the extra flags be
>  conditional on the value of XEN_RELEASE.
> >>>
> >>> If we are sure that it's ignored than it might be benign. Maybe we
> >>> should just add an in-code comment to explain why we added it though.
> >>
> >> Well really, I think that the detection should be put into the qemu
> >> configure scripts -- i.e., it should detect that there's the new API and
> >> add the appropriate #defines itself.  But that's the sort of change I
> >> don't think there will be a lot of enthusiasm for. :-)
> > 
> > Actually there is already code in QEMU configure script for the
> > detection. In fact I was wondering if explicitly passing XC_WANT_* is
> > actually necessary. I don't think it is from QEMU POV.
> 
> That code might be in qemu-upstream, but it's not in the qemu-xen trees;
> if you revert this bit of the patch and try to build with raisin it will
> fail.  That's why I even bothered to add these in in the first place;
> and why IanC added these runes to tools/Makefile.
> 
> Anthony, can you comment more authoritatively here on what's going on?

Yes, easy, xen-4.7 introduce a new API but qemu-xen-4.7 does not know
about it, so qemu-xen will fail to compile. But there are some magic
flags that are use to provide an compatible API and can qemu-xen
compile.

QEMU have been taught about the new API and will use it, without the
magic flags. QEMU will actually ignore the magic flags with a bunch of
#undef.

> Would it be possible for 4.7.1 to backport the configure auto-detection
> stuff?

I think that would be possible. But backporting the use of the new api
will probably be harder. I guess we could just have qemu-xen define the
magic flags itself instead of relying on them been given via a configure
option.


Is that answer your questions?

-- 
Anthony PERARD

Re: [Xen-devel] Xen 4.7 crash

[Wei Liu]

On Tue, Jun 14, 2016 at 09:38:22AM -0400, Aaron Cornelius wrote:
> On 6/14/2016 9:26 AM, Aaron Cornelius wrote:
> >On 6/14/2016 9:15 AM, Wei Liu wrote:
> >>On Tue, Jun 14, 2016 at 09:11:47AM -0400, Aaron Cornelius wrote:
> >>>On 6/9/2016 7:14 AM, Ian Jackson wrote:
> Aaron Cornelius writes ("Re: [Xen-devel] Xen 4.7 crash"):
> >I am not that familiar with the xenstored code, but as far as I can tell
> >the grant mapping will be held by the xenstore until the xs_release()
> >function is called (which is not called by libxl, and I do not
> >explicitly call it in my software, although I might now just to be
> >safe), or until the last reference to a domain is released and the
> >registered destructor (destroy_domain), set by talloc_set_destructor(),
> >is called.
> 
> I'm not sure I follow.  Or maybe I disagree.  ISTM that:
> 
> The grant mapping is released by destroy_domain, which is called via
> the talloc destructor as a result of talloc_free(domain->conn) in
> domain_cleanup.  I don't see other references to domain->conn.
> 
> domain_cleanup calls talloc_free on domain->conn when it sees the
> domain marked as dying in domain_cleanup.
> 
> So I still think that your acl reference ought not to keep the grant
> mapping alive.
> >>>
> >>>It took a while to complete the testing, but we've finished trying to
> >>>reproduce the error using oxenstored instead of the C xenstored.  When the
> >>>condition occurs that caused the error with the C xenstored (on
> >>>4.7.0-rc4/8478c9409a2c6726208e8dbc9f3e455b76725a33), oxenstored does not
> >>>cause the crash.
> >>>
> >>>So for whatever reason, it would appear that the C xenstored does keep the
> >>>grant allocations open, but oxenstored does not.
> >>>
> >>
> >>Can you provide some easy to follow steps to reproduce this issue?
> >>
> >>AFAICT your environment is very specialised, but we should be able to
> >>trigger the issue with plan xenstore-* utilities?
> >
> >I am not sure if the plain xenstore-* utilities will work, but here are
> >the steps to follow:
> >
> >1. Create a non-standard xenstore path: /tool/test
> >2. Create a domU (mini-os/mirage/something small)
> >3. Add the new domU to the /tool/test permissions list (I'm not 100%
> >sure how to do this with the xenstore-* utilities)
> >a. call xs_get_permissions()
> >b. realloc() the permissions block to add the new domain
> >c. call xs_set_permissions()
> >4. Delete the domU from step 2
> >5. Repeat steps 2-4
> >
> >Eventually the xs_set_permissions() function will return an E2BIG error
> >because the list of domains has grown too large.  Sometime after that is
> >when the crash occurs with the C xenstored and the 4.7.0-rc4 version of
> >Xen.  It usually takes around 1200 or so iterations for the crash to occur.
> 
> After writing up those steps I suddenly realized that I think I have a bug
> in my test that might have been causing the bug in the first place. Once I
> get errors returned from xs_set_permissions() I was not properly cleaning up
> the created domains.  So I think this was just a simple case of VMID
> exhaustion by creating more than 255 domUs at the same time.
> 
> In which case this is completely unrelated to xenstore holding on to grant
> allocations, and the C xenstore most likely behaves correctly.
> 

OK, so I will treat this issue as resolved for now. Let us know if you
discover something new.

Wei.

> - Aaron Cornelius
> 

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

Re: [Xen-devel] Xen 4.7 crash

[Aaron Cornelius]

On 6/14/2016 9:26 AM, Aaron Cornelius wrote:

On 6/14/2016 9:15 AM, Wei Liu wrote:

On Tue, Jun 14, 2016 at 09:11:47AM -0400, Aaron Cornelius wrote:

On 6/9/2016 7:14 AM, Ian Jackson wrote:

Aaron Cornelius writes ("Re: [Xen-devel] Xen 4.7 crash"):

I am not that familiar with the xenstored code, but as far as I can tell
the grant mapping will be held by the xenstore until the xs_release()
function is called (which is not called by libxl, and I do not
explicitly call it in my software, although I might now just to be
safe), or until the last reference to a domain is released and the
registered destructor (destroy_domain), set by talloc_set_destructor(),
is called.


I'm not sure I follow.  Or maybe I disagree.  ISTM that:

The grant mapping is released by destroy_domain, which is called via
the talloc destructor as a result of talloc_free(domain->conn) in
domain_cleanup.  I don't see other references to domain->conn.

domain_cleanup calls talloc_free on domain->conn when it sees the
domain marked as dying in domain_cleanup.

So I still think that your acl reference ought not to keep the grant
mapping alive.


It took a while to complete the testing, but we've finished trying to
reproduce the error using oxenstored instead of the C xenstored.  When the
condition occurs that caused the error with the C xenstored (on
4.7.0-rc4/8478c9409a2c6726208e8dbc9f3e455b76725a33), oxenstored does not
cause the crash.

So for whatever reason, it would appear that the C xenstored does keep the
grant allocations open, but oxenstored does not.



Can you provide some easy to follow steps to reproduce this issue?

AFAICT your environment is very specialised, but we should be able to
trigger the issue with plan xenstore-* utilities?


I am not sure if the plain xenstore-* utilities will work, but here are
the steps to follow:

1. Create a non-standard xenstore path: /tool/test
2. Create a domU (mini-os/mirage/something small)
3. Add the new domU to the /tool/test permissions list (I'm not 100%
sure how to do this with the xenstore-* utilities)
a. call xs_get_permissions()
b. realloc() the permissions block to add the new domain
c. call xs_set_permissions()
4. Delete the domU from step 2
5. Repeat steps 2-4

Eventually the xs_set_permissions() function will return an E2BIG error
because the list of domains has grown too large.  Sometime after that is
when the crash occurs with the C xenstored and the 4.7.0-rc4 version of
Xen.  It usually takes around 1200 or so iterations for the crash to occur.


After writing up those steps I suddenly realized that I think I have a 
bug in my test that might have been causing the bug in the first place. 
Once I get errors returned from xs_set_permissions() I was not properly 
cleaning up the created domains.  So I think this was just a simple case 
of VMID exhaustion by creating more than 255 domUs at the same time.


In which case this is completely unrelated to xenstore holding on to 
grant allocations, and the C xenstore most likely behaves correctly.


- Aaron Cornelius


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

Re: [Xen-devel] [PATCH v4 3/3] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server.

[Jan Beulich]

>>> On 14.06.16 at 15:13,  wrote:
> On 14/06/16 11:45, Jan Beulich wrote:
>>> + struct hvm_ioreq_server *s)
>>> +{
>>> +struct p2m_domain *p2m = p2m_get_hostp2m(d);
>>> +int rc;
>>> +
>>> +spin_lock(>ioreq.lock);
>>> +
>>> +if ( flags == 0 )
>>> +{
>>> +rc = -EINVAL;
>>> +if ( p2m->ioreq.server != s )
>>> +goto out;
>>> +
>>> +/* Unmap ioreq server from p2m type by passing flags with 0. */
>>> +p2m->ioreq.server = NULL;
>>> +p2m->ioreq.flags = 0;
>>> +}
>> 
>> What does "passing" refer to in the comment?
> 
> You make the map_memtype_... hypercall with "flags" set to 0.  I'm not
> sure what's unclear about the sentence; how would you put it differently?

I'd use "flushing", or indeed anything that doesn't resemble wording
used to describe how arguments get handed to functions.

>> Locking is somewhat strange here: You protect against the "set"
>> counterpart altering state while you retrieve it, but you don't
>> protect against the returned data becoming stale by the time
>> the caller can consume it. Is that not a problem? (The most
>> concerning case would seem to be a race of hvmop_set_mem_type()
>> with de-registration of the type.)
> 
> How is that different than calling set_mem_type() first, and then
> de-registering without first unmapping all the types?

Didn't we all agree this is something that should be disallowed
anyway (not that I've seen this implemented, i.e. just being
reminded of it by your reply)?

>>> +uint32_t flags; /* IN - types of accesses to be forwarded to the
>>> +   ioreq server. flags with 0 means to unmap the
>>> +   ioreq server */
>>> +#define _HVMOP_IOREQ_MEM_ACCESS_READ 0
>>> +#define HVMOP_IOREQ_MEM_ACCESS_READ \
>>> +(1u << _HVMOP_IOREQ_MEM_ACCESS_READ)
>>> +
>>> +#define _HVMOP_IOREQ_MEM_ACCESS_WRITE 1
>>> +#define HVMOP_IOREQ_MEM_ACCESS_WRITE \
>>> +(1u << _HVMOP_IOREQ_MEM_ACCESS_WRITE)
>> 
>> Is there any use for these _HVMOP_* values? The more that they
>> violate standard C name space rules?
> 
> I assume he's just going along with what he sees in params.h.
> "Violating standard C name space rules" by having #defines which start
> with a single _ seems to be a well-established policy for Xen. :-)

Sadly, and I'm trying to prevent matters becoming worse.
Speaking of which - there are XEN_ prefixes missing here too.

Jan


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

Re: [Xen-devel] Xen 4.7 crash

[Aaron Cornelius]

On 6/14/2016 9:15 AM, Wei Liu wrote:

On Tue, Jun 14, 2016 at 09:11:47AM -0400, Aaron Cornelius wrote:

On 6/9/2016 7:14 AM, Ian Jackson wrote:

Aaron Cornelius writes ("Re: [Xen-devel] Xen 4.7 crash"):

I am not that familiar with the xenstored code, but as far as I can tell
the grant mapping will be held by the xenstore until the xs_release()
function is called (which is not called by libxl, and I do not
explicitly call it in my software, although I might now just to be
safe), or until the last reference to a domain is released and the
registered destructor (destroy_domain), set by talloc_set_destructor(),
is called.


I'm not sure I follow.  Or maybe I disagree.  ISTM that:

The grant mapping is released by destroy_domain, which is called via
the talloc destructor as a result of talloc_free(domain->conn) in
domain_cleanup.  I don't see other references to domain->conn.

domain_cleanup calls talloc_free on domain->conn when it sees the
domain marked as dying in domain_cleanup.

So I still think that your acl reference ought not to keep the grant
mapping alive.


It took a while to complete the testing, but we've finished trying to
reproduce the error using oxenstored instead of the C xenstored.  When the
condition occurs that caused the error with the C xenstored (on
4.7.0-rc4/8478c9409a2c6726208e8dbc9f3e455b76725a33), oxenstored does not
cause the crash.

So for whatever reason, it would appear that the C xenstored does keep the
grant allocations open, but oxenstored does not.



Can you provide some easy to follow steps to reproduce this issue?

AFAICT your environment is very specialised, but we should be able to
trigger the issue with plan xenstore-* utilities?


I am not sure if the plain xenstore-* utilities will work, but here are 
the steps to follow:


1. Create a non-standard xenstore path: /tool/test
2. Create a domU (mini-os/mirage/something small)
3. Add the new domU to the /tool/test permissions list (I'm not 100% 
sure how to do this with the xenstore-* utilities)

   a. call xs_get_permissions()
   b. realloc() the permissions block to add the new domain
   c. call xs_set_permissions()
4. Delete the domU from step 2
5. Repeat steps 2-4

Eventually the xs_set_permissions() function will return an E2BIG error 
because the list of domains has grown too large.  Sometime after that is 
when the crash occurs with the C xenstored and the 4.7.0-rc4 version of 
Xen.  It usually takes around 1200 or so iterations for the crash to occur.


- Aaron Cornelius

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

Re: [Xen-devel] [PATCH v2 2/3] libxl: update vcpus bitmap in retrieved guest config

[Anthony PERARD]

On Tue, Jun 14, 2016 at 11:58:58AM +0100, Anthony PERARD wrote:
> On Tue, Jun 14, 2016 at 11:50:12AM +0100, Wei Liu wrote:
> > On Tue, Jun 14, 2016 at 11:47:57AM +0100, Anthony PERARD wrote:
> > [...]
> > > > > > +
> > > > > >  int libxl_retrieve_domain_configuration(libxl_ctx *ctx, uint32_t 
> > > > > > domid,
> > > > > >  libxl_domain_config 
> > > > > > *d_config)
> > > > > >  {
> > > > > > @@ -7270,6 +7317,46 @@ int 
> > > > > > libxl_retrieve_domain_configuration(libxl_ctx *ctx, uint32_t domid,
> > > > > >  libxl_dominfo_dispose();
> > > > > >  }
> > > > > >  
> > > > > > +/* VCPUs */
> > > > > > +{
> > > > > > +libxl_bitmap *map = _config->b_info.avail_vcpus;
> > > > > > +unsigned int max_vcpus = d_config->b_info.max_vcpus;
> > > > > > +
> > > > > > +libxl_bitmap_dispose(map);
> > > > > > +libxl_bitmap_init(map);
> > > > > > +libxl_bitmap_alloc(CTX, map, max_vcpus);
> > > > > > +libxl_bitmap_set_none(map);
> > > > > > +
> > > > > > +switch (d_config->b_info.type) {
> > > > > > +case LIBXL_DOMAIN_TYPE_HVM:
> > > > > > +switch (d_config->b_info.device_model_version) {
> > > > > > +case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
> > > > > > +rc = libxl__update_avail_vcpus_qmp(gc, domid,
> > > > > > +   max_vcpus, map);
> > > > > > +break;
> > > > > > +case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
> > > > > > +case LIBXL_DEVICE_MODEL_VERSION_NONE:
> > > > > > +rc = libxl__update_avail_vcpus_xenstore(gc, domid,
> > > > > > +max_vcpus, 
> > > > > > map);
> > > > > > +break;
> > > > > > +default:
> > > > > > +abort();
> > > > > 
> > > > > Missing indentation for abort.
> > > > > 
> > > > 
> > > > Will fix.
> > > > 
> > > > > Also, that is where xl abort on migration.
> > > > > 
> > > > 
> > > > Hmm...  This means the device model version is not valid (unknown?).
> > > > 
> > > > Can you paste in your guest config?
> > > 
> > > With all commented line removed:
> > > 
> > > builder = 'hvm'
> > > memory = 500
> > > vcpus = 2
> > > maxvcpus = 6
> > > name = "arch"
> > > vif = [ 'type=ioemu,mac=00:16:3e:XX:XX:XX' ]
> > > disk = [
> > > 'phy:/dev/vg42/guest_arch64,hda,w',
> > >  'file:/root/vm/iso/archlinux-2014.04.01-dual.iso,hdc:cdrom,r',
> > > ]
> > > device_model_args_hvm = [
> > > ]
> > > usbdevice='tablet'
> > > boot="cd"
> > > serial='pty'
> > > sdl = 0
> > > vnc = 1
> > > vnclisten = '0.0.0.0'
> > > vncunused = 1
> > > spice=0
> > > uuid = ""
> > > 
> > 
> > This means your device model version is LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN
> > so it should be covered by the correct case.
> > 
> > I'm confused.
> 
> If it works for you, I'll properly install Xen with your patch in,
> I may miss something...
> I did:
> LD_LIBRARY_PATH=`pwd` ./xl -vvv migrate arch localhost

I tried again, this time Xen properly installed with your patch series.

sh$ xl create arch.hvm
sh$ xl list
NameID   Mem VCPUs  State   Time(s)
Domain-0 0  4000 8 r-  25.3
arch 1   500 2 -b   5.4
sh$ xl vcpu-set arch 5
sh$ xl list
NameID   Mem VCPUs  State   Time(s)
Domain-0 0  4000 8 r-  25.8
arch 1   500 5 -b   6.4

# All fine up to here.

sh$ xl migrate arch localhost
Aborted (core dumped)
sh$  xl save arch savefile
Aborted (core dumped)
sh$ xl save arch savefile ~/arch.hvm
Saving to savefile new xl format (info 0x3/0x0/1540)
xc: info: Saving domain 1, type x86 HVM
xc: Frames: 1044482/1044482  100%
xc: End of stream: 0/00%

# So there is only one way to migrate or save the guest.

sh$ xl restore savefile
[...]
libxl: error: libxl_dm.c:2187:device_model_spawn_outcome: domain 2 device 
model: spawn failed (rc=-3)
[...]

# So restore still fail with this in QEMU log:
qemu-system-i386: Unknown savevm section or instance 'cpu_common' 2
qemu-system-i386: load of migration failed: Invalid argument

-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH 00/17] Honour more configure variables in various places (iteration 2)

[Wei Liu]

On Mon, Jun 13, 2016 at 08:48:58AM +0100, Wei Liu wrote:
> The first three patches are carried over from previous series.
> 
> The rest introduce some new variables and replace various hard-coded paths in
> code.
> 
> There is one more path /var/run, with which I'm not sure what to do for the
> moment. More patches will come to deal with it.
> 
> Wei.
> 
> Wei Liu (17):
>   oxenstored: honour XEN_{LOG,RUN}_DIR in oxenstored.conf
>   oxenstored: generate a paths module
>   oxenstored: honour XEN_LOG_DIR defined by configure
>   build: introduce and export XEN_LIB_DIR
>   tools: install and remove XEN_LIB_DIR in Makefile
>   hotplug/Linux: honour XEN_LIB_DIR
>   libxl: honour XEN_LIB_DIR
>   tools: remove hard-coded /var/lib/xen in Makefile

I've queued up these seven.

>   docs: honour XEN_DUMP_DIR

This is acked but we would like to wait a bit.

>   build: introduce XEN_RUN_STORED

This is not yet acked.

>   hotplug/Linux: honour XEN_RUN_STORED
>   libxenstore: honour XEN_RUN_STORED
>   hotplug/FreeBSD: honour XEN_RUN_STORED

These are acked but depend on the introduction of XEN_RUN_STORED.

>   ocaml/libxs: generate a paths.ml
>   ocaml/libxs: honour XEN_RUN_STORED
>   oxenstored: honour XEN_RUN_STORED and XEN_CONFIG_DIR
>   oxenstored: honour XEN_RUN_STORED in systemd C stub

The last three are not yet acked. Will wait for David to express his
opinion.

Wei.

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

Re: [Xen-devel] [PATCH v4 1/3] x86/ioreq server: Rename p2m_mmio_write_dm to p2m_ioreq_server.

[George Dunlap]

On 14/06/16 11:04, Jan Beulich wrote:
 On 19.05.16 at 11:05,  wrote:
>> @@ -5507,6 +5507,8 @@ long do_hvm_op(unsigned long op, 
>> XEN_GUEST_HANDLE_PARAM(void) arg)
>>  get_gfn_query_unlocked(d, a.pfn, );
>>  if ( p2m_is_mmio(t) )
>>  a.mem_type =  HVMMEM_mmio_dm;
>> +else if ( t == p2m_ioreq_server )
>> +a.mem_type = HVMMEM_ioreq_server;
>>  else if ( p2m_is_readonly(t) )
>>  a.mem_type =  HVMMEM_ram_ro;
>>  else if ( p2m_is_ram(t) )
> 
> I can see this being suitable to be done here, but ...
> 
>> @@ -5537,7 +5539,8 @@ long do_hvm_op(unsigned long op, 
>> XEN_GUEST_HANDLE_PARAM(void) arg)
>>  [HVMMEM_ram_rw]  = p2m_ram_rw,
>>  [HVMMEM_ram_ro]  = p2m_ram_ro,
>>  [HVMMEM_mmio_dm] = p2m_mmio_dm,
>> -[HVMMEM_unused] = p2m_invalid
>> +[HVMMEM_unused] = p2m_invalid,
>> +[HVMMEM_ioreq_server] = p2m_ioreq_server
>>  };
>>  
>>  if ( copy_from_guest(, arg, 1) )
> 
> ... how can this be correct without actual handling having got added?
> IOW doesn't at least this change belong into a later patch?

+1

With that change:

Acked-by: George Dunlap 


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

Re: [Xen-devel] [PATCH v4 3/3] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server.

[George Dunlap]

On 19/05/16 10:05, Yu Zhang wrote:
> A new HVMOP - HVMOP_map_mem_type_to_ioreq_server, is added to
> let one ioreq server claim/disclaim its responsibility for the
> handling of guest pages with p2m type p2m_ioreq_server. Users
> of this HVMOP can specify which kind of operation is supposed
> to be emulated in a parameter named flags. Currently, this HVMOP
> only support the emulation of write operations. And it can be
> easily extended to support the emulation of read ones if an
> ioreq server has such requirement in the future.
> 
> For now, we only support one ioreq server for this p2m type, so
> once an ioreq server has claimed its ownership, subsequent calls
> of the HVMOP_map_mem_type_to_ioreq_server will fail. Users can also
> disclaim the ownership of guest ram pages with p2m_ioreq_server, by
> triggering this new HVMOP, with ioreq server id set to the current
> owner's and flags parameter set to 0.
> 
> Note both HVMOP_map_mem_type_to_ioreq_server and p2m_ioreq_server
> are only supported for HVMs with HAP enabled.
> 
> Also note that only after one ioreq server claims its ownership
> of p2m_ioreq_server, will the p2m type change to p2m_ioreq_server
> be allowed.
> 
> Signed-off-by: Paul Durrant 
> Signed-off-by: Yu Zhang 
> Acked-by: Tim Deegan 

Looks OK to me:

Acked-by: George Dunlap 

> ---
> Cc: Paul Durrant 
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> Cc: George Dunlap 
> Cc: Jun Nakajima 
> Cc: Kevin Tian 
> Cc: Tim Deegan 
> 
> changes in v4:
>   - According to Paul's advice, add comments around the definition
> of HVMMEM_iore_server in hvm_op.h.
>   - According to Wei Liu's comments, change the format of the commit
> message.
> 
> changes in v3:
>   - Only support write emulation in this patch;
>   - Remove the code to handle race condition in hvmemul_do_io(),
>   - No need to reset the p2m type after an ioreq server has disclaimed
> its ownership of p2m_ioreq_server;
>   - Only allow p2m type change to p2m_ioreq_server after an ioreq
> server has claimed its ownership of p2m_ioreq_server;
>   - Only allow p2m type change to p2m_ioreq_server from pages with type
> p2m_ram_rw, and vice versa;
>   - HVMOP_map_mem_type_to_ioreq_server interface change - use uint16,
> instead of enum to specify the memory type;
>   - Function prototype change to p2m_get_ioreq_server();
>   - Coding style changes;
>   - Commit message changes;
>   - Add Tim's Acked-by.
> 
> changes in v2: 
>   - Only support HAP enabled HVMs;
>   - Replace p2m_mem_type_changed() with p2m_change_entry_type_global()
> to reset the p2m type, when an ioreq server tries to claim/disclaim
> its ownership of p2m_ioreq_server;
>   - Comments changes.
> ---
>  xen/arch/x86/hvm/emulate.c   | 32 --
>  xen/arch/x86/hvm/hvm.c   | 63 ++--
>  xen/arch/x86/hvm/ioreq.c | 41 +++
>  xen/arch/x86/mm/hap/nested_hap.c |  2 +-
>  xen/arch/x86/mm/p2m-ept.c|  7 +++-
>  xen/arch/x86/mm/p2m-pt.c | 23 +
>  xen/arch/x86/mm/p2m.c| 70 
> 
>  xen/arch/x86/mm/shadow/multi.c   |  3 +-
>  xen/include/asm-x86/hvm/ioreq.h  |  2 ++
>  xen/include/asm-x86/p2m.h| 30 +++--
>  xen/include/public/hvm/hvm_op.h  | 35 +++-
>  11 files changed, 289 insertions(+), 19 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
> index b9cac8e..4571294 100644
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -100,6 +100,7 @@ static int hvmemul_do_io(
>  uint8_t dir, bool_t df, bool_t data_is_addr, uintptr_t data)
>  {
>  struct vcpu *curr = current;
> +struct domain *currd = curr->domain;
>  struct hvm_vcpu_io *vio = >arch.hvm_vcpu.hvm_io;
>  ioreq_t p = {
>  .type = is_mmio ? IOREQ_TYPE_COPY : IOREQ_TYPE_PIO,
> @@ -141,7 +142,7 @@ static int hvmemul_do_io(
>   (p.dir != dir) ||
>   (p.df != df) ||
>   (p.data_is_ptr != data_is_addr) )
> -domain_crash(curr->domain);
> +domain_crash(currd);
>  
>  if ( data_is_addr )
>  return X86EMUL_UNHANDLEABLE;
> @@ -178,8 +179,33 @@ static int hvmemul_do_io(
>  break;
>  case X86EMUL_UNHANDLEABLE:
>  {
> -struct hvm_ioreq_server *s =
> -hvm_select_ioreq_server(curr->domain, );
> +struct hvm_ioreq_server *s;
> +p2m_type_t p2mt;
> +
> +if ( is_mmio )
> +{
> +unsigned long gmfn = paddr_to_pfn(addr);
> +
> +(void) get_gfn_query_unlocked(currd, gmfn, );
> +
> +if ( p2mt == p2m_ioreq_server )
> +   

Re: [Xen-devel] Xen 4.7 crash

[Wei Liu]

On Tue, Jun 14, 2016 at 09:11:47AM -0400, Aaron Cornelius wrote:
> On 6/9/2016 7:14 AM, Ian Jackson wrote:
> >Aaron Cornelius writes ("Re: [Xen-devel] Xen 4.7 crash"):
> >>I am not that familiar with the xenstored code, but as far as I can tell
> >>the grant mapping will be held by the xenstore until the xs_release()
> >>function is called (which is not called by libxl, and I do not
> >>explicitly call it in my software, although I might now just to be
> >>safe), or until the last reference to a domain is released and the
> >>registered destructor (destroy_domain), set by talloc_set_destructor(),
> >>is called.
> >
> >I'm not sure I follow.  Or maybe I disagree.  ISTM that:
> >
> >The grant mapping is released by destroy_domain, which is called via
> >the talloc destructor as a result of talloc_free(domain->conn) in
> >domain_cleanup.  I don't see other references to domain->conn.
> >
> >domain_cleanup calls talloc_free on domain->conn when it sees the
> >domain marked as dying in domain_cleanup.
> >
> >So I still think that your acl reference ought not to keep the grant
> >mapping alive.
> 
> It took a while to complete the testing, but we've finished trying to
> reproduce the error using oxenstored instead of the C xenstored.  When the
> condition occurs that caused the error with the C xenstored (on
> 4.7.0-rc4/8478c9409a2c6726208e8dbc9f3e455b76725a33), oxenstored does not
> cause the crash.
> 
> So for whatever reason, it would appear that the C xenstored does keep the
> grant allocations open, but oxenstored does not.
> 

Can you provide some easy to follow steps to reproduce this issue?

AFAICT your environment is very specialised, but we should be able to
trigger the issue with plan xenstore-* utilities?

Wei.

> - Aaron Cornelius
> 

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

Re: [Xen-devel] [PATCH v4 3/3] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server.

[George Dunlap]

On 14/06/16 11:45, Jan Beulich wrote:
>> + struct hvm_ioreq_server *s)
>> +{
>> +struct p2m_domain *p2m = p2m_get_hostp2m(d);
>> +int rc;
>> +
>> +spin_lock(>ioreq.lock);
>> +
>> +if ( flags == 0 )
>> +{
>> +rc = -EINVAL;
>> +if ( p2m->ioreq.server != s )
>> +goto out;
>> +
>> +/* Unmap ioreq server from p2m type by passing flags with 0. */
>> +p2m->ioreq.server = NULL;
>> +p2m->ioreq.flags = 0;
>> +}
> 
> What does "passing" refer to in the comment?

You make the map_memtype_... hypercall with "flags" set to 0.  I'm not
sure what's unclear about the sentence; how would you put it differently?

> Locking is somewhat strange here: You protect against the "set"
> counterpart altering state while you retrieve it, but you don't
> protect against the returned data becoming stale by the time
> the caller can consume it. Is that not a problem? (The most
> concerning case would seem to be a race of hvmop_set_mem_type()
> with de-registration of the type.)

How is that different than calling set_mem_type() first, and then
de-registering without first unmapping all the types?

>> +uint32_t flags; /* IN - types of accesses to be forwarded to the
>> +   ioreq server. flags with 0 means to unmap the
>> +   ioreq server */
>> +#define _HVMOP_IOREQ_MEM_ACCESS_READ 0
>> +#define HVMOP_IOREQ_MEM_ACCESS_READ \
>> +(1u << _HVMOP_IOREQ_MEM_ACCESS_READ)
>> +
>> +#define _HVMOP_IOREQ_MEM_ACCESS_WRITE 1
>> +#define HVMOP_IOREQ_MEM_ACCESS_WRITE \
>> +(1u << _HVMOP_IOREQ_MEM_ACCESS_WRITE)
> 
> Is there any use for these _HVMOP_* values? The more that they
> violate standard C name space rules?

I assume he's just going along with what he sees in params.h.
"Violating standard C name space rules" by having #defines which start
with a single _ seems to be a well-established policy for Xen. :-)

 -George

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

Re: [Xen-devel] [PATCH 8/8] xen/arm: p2m_cache_flush: Use the correct terminology and typesafe gfn

[Andrew Cooper]

On 14/06/16 13:07, Julien Grall wrote:
> p2m_cache_flush is expecting GFNs in parameter and not MFNs. Rename
> the variable to *gfn* and use typesafe to avoid possible misusage.
>
> Signed-off-by: Julien Grall 
> ---
>  xen/arch/arm/domctl.c |  2 +-
>  xen/arch/arm/p2m.c| 10 +-
>  xen/include/asm-arm/p2m.h |  2 +-
>  3 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c
> index 30453d8..b94e97c 100644
> --- a/xen/arch/arm/domctl.c
> +++ b/xen/arch/arm/domctl.c
> @@ -30,7 +30,7 @@ long arch_do_domctl(struct xen_domctl *domctl, struct 
> domain *d,
>  if ( e < s )
>  return -EINVAL;
>  
> -return p2m_cache_flush(d, s, e);
> +return p2m_cache_flush(d, _gfn(s), _gfn(e));
>  }
>  case XEN_DOMCTL_bind_pt_irq:
>  {
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index 135d032..d50eda3 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -1467,16 +1467,16 @@ int relinquish_p2m_mapping(struct domain *d)
>d->arch.p2m.default_access);
>  }
>  
> -int p2m_cache_flush(struct domain *d, xen_pfn_t start_mfn, xen_pfn_t end_mfn)
> +int p2m_cache_flush(struct domain *d, gfn_t start_gfn, gfn_t end_gfn)

I would recommend dropping the _gfn suffix from start and end.  It only
serves to make the code longer, as the numbers are of gfn_t type.

~Andrew

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

Re: [Xen-devel] Xen 4.7 crash

[Aaron Cornelius]

On 6/9/2016 7:14 AM, Ian Jackson wrote:

Aaron Cornelius writes ("Re: [Xen-devel] Xen 4.7 crash"):

I am not that familiar with the xenstored code, but as far as I can tell
the grant mapping will be held by the xenstore until the xs_release()
function is called (which is not called by libxl, and I do not
explicitly call it in my software, although I might now just to be
safe), or until the last reference to a domain is released and the
registered destructor (destroy_domain), set by talloc_set_destructor(),
is called.


I'm not sure I follow.  Or maybe I disagree.  ISTM that:

The grant mapping is released by destroy_domain, which is called via
the talloc destructor as a result of talloc_free(domain->conn) in
domain_cleanup.  I don't see other references to domain->conn.

domain_cleanup calls talloc_free on domain->conn when it sees the
domain marked as dying in domain_cleanup.

So I still think that your acl reference ought not to keep the grant
mapping alive.


It took a while to complete the testing, but we've finished trying to 
reproduce the error using oxenstored instead of the C xenstored.  When 
the condition occurs that caused the error with the C xenstored (on 
4.7.0-rc4/8478c9409a2c6726208e8dbc9f3e455b76725a33), oxenstored does not 
cause the crash.


So for whatever reason, it would appear that the C xenstored does keep 
the grant allocations open, but oxenstored does not.


- Aaron Cornelius


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

Re: [Xen-devel] [PATCH 7/8] xen/mm: Introduce max_gfn and min_gfn

[Andrew Cooper]

On 14/06/16 14:05, Jan Beulich wrote:
 On 14.06.16 at 14:07,  wrote:
>> --- a/xen/include/xen/mm.h
>> +++ b/xen/include/xen/mm.h
>> @@ -70,6 +70,9 @@ TYPE_SAFE(unsigned long, gfn);
>>  #undef gfn_t
>>  #endif
>>  
>> +#define max_gfn(x, y) _gfn(max(gfn_x(x), gfn_x(y)))
>> +#define min_gfn(x, y) _gfn(min(gfn_x(x), gfn_x(y)))
> With my reply to an earlier patch in mind I think these would better
> be gfn_min() and gfn_max() (to be extended with gfn_add() and
> mfn_add() and maybe some others).

+1 to the alternative naming suggestion.

I would also suggest making these static inlines rather than defines.

~Andrew

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

Re: [Xen-devel] [PATCH 0/6] xl/libxl: some cleanup / debugging aid patches

[Wei Liu]

On Mon, Jun 06, 2016 at 11:52:06AM +0100, Wei Liu wrote:
> A handful of patches I accumulated during freeze when I was debugging various
> issues in xl / libxl.
> 
> Wei.
> 
> Wei Liu (6):
>   xl: remus/colo: only initialise ha variable when necessary
>   libxl: add emacs block to libxl_linux.c
>   libxl: linux hotplug: clean up get_hotplug_env
>   libxl: debug output for args and env when invoking hotplug script
>   libxl: rename a field in libxl__domain_create_state
>   libxl: log file name in failure in libxl__create_qemu_logfile
> 

I've queued up all the acked patches (2, 3, 5 and 6) for committing.

Wei.

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

Re: [Xen-devel] [PATCH 7/8] xen/mm: Introduce max_gfn and min_gfn

[Jan Beulich]

>>> On 14.06.16 at 14:07,  wrote:
> --- a/xen/include/xen/mm.h
> +++ b/xen/include/xen/mm.h
> @@ -70,6 +70,9 @@ TYPE_SAFE(unsigned long, gfn);
>  #undef gfn_t
>  #endif
>  
> +#define max_gfn(x, y) _gfn(max(gfn_x(x), gfn_x(y)))
> +#define min_gfn(x, y) _gfn(min(gfn_x(x), gfn_x(y)))

With my reply to an earlier patch in mind I think these would better
be gfn_min() and gfn_max() (to be extended with gfn_add() and
mfn_add() and maybe some others).

Jan


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

Re: [Xen-devel] [PATCH 5/8] xen: Use the typesafe mfn and gfn in map_mmio_regions...

[Jan Beulich]

>>> On 14.06.16 at 14:07,  wrote:
> to avoid mixing machine frame with guest frame.
> 
> Signed-off-by: Julien Grall 

Non-ARM bits:
Acked-by: Jan Beulich 

> @@ -2217,10 +2217,11 @@ int map_mmio_regions(struct domain *d,
>i += 1UL << order, ++iter )
>  {
>  /* OR'ing gfn and mfn values will return an order suitable to both. 
> */
> -for ( order = mmio_order(d, (start_gfn + i) | (mfn + i), nr - i); ;
> +for ( order = mmio_order(d, (gfn_x(start_gfn) + i) | (mfn_x(mfn) + 
> i), nr - i); ;
>order = ret - 1 )
>  {
> -ret = set_mmio_p2m_entry(d, start_gfn + i, _mfn(mfn + i), order,
> +ret = set_mmio_p2m_entry(d, gfn_x(start_gfn) + i,
> + _mfn(mfn_x(mfn) + i), order,

Considering this new instance I realize we really should have
constructs like mfn_add() to avoid such ugly to read expressions.

Jan


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

Re: [Xen-devel] [PATCH 4/8] xen/arm: Rename grant_table_gfpn into grant_table_gfn and use the typesafe gfn

[Andrew Cooper]

On 14/06/16 13:07, Julien Grall wrote:
> diff --git a/xen/include/asm-arm/grant_table.h 
> b/xen/include/asm-arm/grant_table.h
> index 5e076cc..46cfe24 100644
> --- a/xen/include/asm-arm/grant_table.h
> +++ b/xen/include/asm-arm/grant_table.h
> @@ -30,7 +30,7 @@ static inline int replace_grant_supported(void)
>  
>  #define gnttab_shared_gmfn(d, t, i)  \
>  ( ((i >= nr_grant_frames(d->grant_table)) && \
> - (i < max_grant_frames)) ? 0 : (d->arch.grant_table_gpfn[i]))
> + (i < max_grant_frames)) ? 0 : gfn_x((d->arch.grant_table_gfn[i])))

One small nit.  You can drop one pair of brackets inside the gfn_x() call.

~Andrew

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

Re: [Xen-devel] [PATCH 3/8] xen: Use typesafe gfn in xenmem_add_to_physmap_one

[Jan Beulich]

>>> On 14.06.16 at 14:07,  wrote:
> The x86 version of the function xenmem_add_to_physmap_one contains
> variable name gpfn and gfn which make the code very confusing.
> I have left unchanged for now.
> 
> Also, rename gpfn to gfn in the ARM version as the latter is the correct
> acronym for a guest physical frame.
> 
> Finally, remove the trailing whitespace around the changes.
> 
> Signed-off-by: Julien Grall 

Non-ARM bits:
Acked-by: Jan Beulich 


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

Re: [Xen-devel] [PATCH 2/8] xen: Use typesafe gfn/mfn in guest_physmap_* helpers

[Jan Beulich]

>>> On 14.06.16 at 14:07,  wrote:
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -665,21 +665,21 @@ p2m_remove_page(struct p2m_domain *p2m, unsigned long 
> gfn, unsigned long mfn,
>  }
>  
>  int
> -guest_physmap_remove_page(struct domain *d, unsigned long gfn,
> -  unsigned long mfn, unsigned int page_order)
> +guest_physmap_remove_page(struct domain *d, gfn_t gfn,
> +  mfn_t mfn, unsigned int page_order)
>  {
>  struct p2m_domain *p2m = p2m_get_hostp2m(d);
>  int rc;
>  gfn_lock(p2m, gfn, page_order);
> -rc = p2m_remove_page(p2m, gfn, mfn, page_order);
> +rc = p2m_remove_page(p2m, gfn_x(gfn), mfn_x(mfn), page_order);
>  gfn_unlock(p2m, gfn, page_order);
>  return rc;
>  }
>  
> -int
> -guest_physmap_add_entry(struct domain *d, unsigned long gfn,
> -unsigned long mfn, unsigned int page_order, 
> -p2m_type_t t)
> +static int
> +__guest_physmap_add_entry(struct domain *d, unsigned long gfn,

At the very least only a single underscore please.

> +  unsigned long mfn, unsigned int page_order,
> +  p2m_type_t t)
>  {
>  struct p2m_domain *p2m = p2m_get_hostp2m(d);
>  unsigned long i, ogfn;
> @@ -838,6 +838,13 @@ out:
>  return rc;
>  }
>  
> +/* XXX: To be removed when __guest_physmap_add_entry will use typesafe */

But not just because of this (misleading) comment I really wonder
what the point here is: Is it really that much more intrusive to
change the function right away instead of introducing a wrapper?
(The comment is misleading because __guest_physmap_add_entry
shouldn't survive after the conversion to proper types, i.e. it is
not the function below which is supposed to get removed.)

> +int
> +guest_physmap_add_entry(struct domain *d, gfn_t gfn, mfn_t mfn,
> +unsigned int page_order, p2m_type_t t)
> +{
> +return __guest_physmap_add_entry(d, gfn_x(gfn), mfn_x(mfn), page_order, 
> t);
> +}

Perhaps a better (wrapper-less) approach (if full conversion is indeed
beyond scope) would be to simply rename the function parameters
and have local variables named "gfn" and "mfn"?

> @@ -2785,7 +2792,8 @@ int p2m_add_foreign(struct domain *tdom, unsigned long 
> fgfn,
>  unsigned long gpfn, domid_t foreigndom)
>  {
>  p2m_type_t p2mt, p2mt_prev;
> -unsigned long prev_mfn, mfn;
> +mfn_t prev_mfn;
> +unsigned long mfn;

This looks to make things more inconsistent rather than more consistent.

Jan


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

Re: [Xen-devel] [PATCH 1/8] xen/arm: Rename gmfn_to_mfn to gfn_to_mfn and use gfn/mfn typesafe

[Julien Grall]

On 14/06/16 13:44, Jan Beulich wrote:

On 14.06.16 at 14:07,  wrote:

The correct acronym for a guest physical frame is gfn. Also use
the recently introduced typesafe gfn/mfn to avoid mixing the two
different kind of frame.

Signed-off-by: Julien Grall 
---
  xen/arch/arm/p2m.c| 6 +++---
  xen/common/grant_table.c  | 4 ++--
  xen/common/memory.c   | 4 ++--
  xen/include/asm-arm/p2m.h | 2 +-
  4 files changed, 8 insertions(+), 8 deletions(-)


Acked-by: Jan Beulich 

(please don't forget to always Cc all relevant maintainers)


Sorry I forgot to double check what was modified by the patch. I saw 
"xen/arm:" in the title and thought it was ARM only.


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 4/6] libxl: debug output for args and env when invoking hotplug script

[Wei Liu]

On Tue, Jun 14, 2016 at 11:26:56AM +0100, Ian Jackson wrote:
> Wei Liu writes ("[PATCH 4/6] libxl: debug output for args and env when 
> invoking hotplug script"):
> > Signed-off-by: Wei Liu 
> ...
> > +const char *arg;
> > +unsigned int x = 2;
> > +
> > +arg = args[x];
> > +while (arg) {
> > +LOG(DEBUG, "\t%s", arg);
> > +x++;
> > +arg = args[x];
> > +}

I will use

> 
> What a strange way to write
> 
>for (x=2; (arg = args[x]); x++) {
> 

This style.

> or
> 
>for (x=2; (arg = args[x++]); ) {
> 
> or
> 
>x = 2;
>while ((arg = args[x++])) {
> 
> If you really insist on not doing assignment in the conditional (which
> IMO is a very usual C idiom) then you should avoid the repeated code
> with
> 
>x = 2;
>for (;;) {
>   arg = args[x++];
>   if (!arg) break;
> 
> or some such.
> 
> > +const char *k, *v;
> > +unsigned int x = 0;
> > +
> > +k = env[x];
> > +while (k) {
> > +v = env[x+1];
> > +LOG(DEBUG, "\t%s: %s", k, v);
> > +x += 2;
> > +k = env[x];
> > +}
> 
> How about one of
> 
>for (x=0; (k = env[x]); x += 2) {
>v = env[x+1];
> 

And this style.

---8<---
From 49714976c5fde3d08baa6f34295b3f7db6a81444 Mon Sep 17 00:00:00 2001
From: Wei Liu 
Date: Fri, 15 Apr 2016 12:56:03 +0100
Subject: [PATCH] libxl: debug output for args and env when invoking hotplug
 script

Signed-off-by: Wei Liu 
---
v2: write the loops differently.
---
 tools/libxl/libxl_device.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index 4717027..b3213be 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -1167,6 +1167,24 @@ static void device_hotplug(libxl__egc *egc, 
libxl__ao_device *aodev)
 }
 
 LOG(DEBUG, "calling hotplug script: %s %s", args[0], args[1]);
+LOG(DEBUG, "extra args:");
+{
+const char *arg;
+unsigned int x;
+
+for (x = 2; (arg = args[x]); x++)
+LOG(DEBUG, "\t%s", arg);
+}
+LOG(DEBUG, "env:");
+{
+const char *k, *v;
+unsigned int x;
+
+for (x = 0; (k = env[x]); x += 2) {
+v = env[x+1];
+LOG(DEBUG, "\t%s: %s", k, v);
+}
+}
 
 nullfd = open("/dev/null", O_RDONLY);
 if (nullfd < 0) {
-- 
2.1.4


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

Re: [Xen-devel] [PATCH 1/8] xen/arm: Rename gmfn_to_mfn to gfn_to_mfn and use gfn/mfn typesafe

[Jan Beulich]

>>> On 14.06.16 at 14:07,  wrote:
> The correct acronym for a guest physical frame is gfn. Also use
> the recently introduced typesafe gfn/mfn to avoid mixing the two
> different kind of frame.
> 
> Signed-off-by: Julien Grall 
> ---
>  xen/arch/arm/p2m.c| 6 +++---
>  xen/common/grant_table.c  | 4 ++--
>  xen/common/memory.c   | 4 ++--
>  xen/include/asm-arm/p2m.h | 2 +-
>  4 files changed, 8 insertions(+), 8 deletions(-)

Acked-by: Jan Beulich 

(please don't forget to always Cc all relevant maintainers)


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

Re: [Xen-devel] xen/x86: efi: warning value truncated

[Jan Beulich]

>>> On 14.06.16 at 13:19,  wrote:
> On 06/14/2016 11:50 AM, Jan Beulich wrote:
> On 14.06.16 at 12:15,  wrote:
>>> On 06/14/2016 10:24 AM, Jan Beulich wrote:
>>> On 13.06.16 at 19:13,  wrote:
> I noticed the warnings below when building Xen x86
> with Livepatch enabled.

 I did notice some of these too (not as many though, iirc), but I
 didn't get around yet to check what exactly is causing them. Since
 they're in the symbol table files only, I didn't consider them too
 concerning (at worst some odd symbol won't be found or be
 associated with the wrong address).

>>>
>>> On my build, they are:
>>>
>>> multiboot1_header_start|051e|   ?  |
>>> multiboot1_header_start|08a1|   ?  |
>>> multiboot1_header_start|08a3|   ?  |
>>> multiboot1_header_start|08a8|   ?  |
>>> multiboot1_header_start|102f|   ?  |
>>> multiboot1_header_start|1033|   ?  |
>>> multiboot1_header_start|1037|   ?  |
>>> __init_end |82d18065| D |
>>
>> Aren't these symbols from the final binary (which get wrongly named
>> without fixed binutils)? Whereas Julien's issue was with warnings from
>> the assembler?
> 
> It looks the same to me. Here are the warnings:
> 
> /home/ross/src/xen/xen/.xen.efi.0s.S: Assembler messages:
> /home/ross/src/xen/xen/.xen.efi.0s.S:21: Warning: value 0x7d2f851e 
> truncated to 0x851e
> /home/ross/src/xen/xen/.xen.efi.0s.S:22: Warning: value 0x7d2f88a1 
> truncated to 0x88a1
> /home/ross/src/xen/xen/.xen.efi.0s.S:23: Warning: value 0x7d2f88a3 
> truncated to 0x88a3
> /home/ross/src/xen/xen/.xen.efi.0s.S:24: Warning: value 0x7d2f88a8 
> truncated to 0x88a8
> /home/ross/src/xen/xen/.xen.efi.0s.S:25: Warning: value 0x7d2f8000102f 
> truncated to 0x8000102f
> /home/ross/src/xen/xen/.xen.efi.0s.S:26: Warning: value 0x7d2f80001033 
> truncated to 0x80001033
> /home/ross/src/xen/xen/.xen.efi.0s.S:27: Warning: value 0x7d2f80001037 
> truncated to 0x80001037
> /home/ross/src/xen/xen/.xen.efi.0s.S:6741: Warning: value 0x10065 
> truncated to 0x65
> /home/ross/src/xen/xen/.xen.efi.1s.S: Assembler messages:
> /home/ross/src/xen/xen/.xen.efi.1s.S:21: Warning: value 0x7d2f851e 
> truncated to 0x851e
> /home/ross/src/xen/xen/.xen.efi.1s.S:22: Warning: value 0x7d2f88a1 
> truncated to 0x88a1
> /home/ross/src/xen/xen/.xen.efi.1s.S:23: Warning: value 0x7d2f88a3 
> truncated to 0x88a3
> /home/ross/src/xen/xen/.xen.efi.1s.S:24: Warning: value 0x7d2f88a8 
> truncated to 0x88a8
> /home/ross/src/xen/xen/.xen.efi.1s.S:25: Warning: value 0x7d2f8000102f 
> truncated to 0x8000102f
> /home/ross/src/xen/xen/.xen.efi.1s.S:26: Warning: value 0x7d2f80001033 
> truncated to 0x80001033
> /home/ross/src/xen/xen/.xen.efi.1s.S:27: Warning: value 0x7d2f80001037 
> truncated to 0x80001037
> /home/ross/src/xen/xen/.xen.efi.1s.S:6740: Warning: value 0x10065 
> truncated to 0x65
> 
> So, e.g. taking the last one, the assembly file contains a line:
> PTR 0x82d18065 - SYMBOLS_ORIGIN
> 
> In this case SYMBOLS_ORIGIN is 0x82d08000 and so it resolves to:
> .long 0x10065
> which overflows.

Oh, right, I got confused. These are wrong because the intermediate
binary had bogus symbol table entries. So indeed these should be gone
with recent enough binutils. And I have to admit that I then have no
idea how to prevent those warnings.

Jan


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

Re: [Xen-devel] [PATCH v3 16/16] xen/arm: arm64: Document Cortex-A57 erratum 834220

[Julien Grall]

Hello,

On 07/06/16 17:06, Julien Grall wrote:

The ARM erratum applies to certain revisions of Cortex-A57. The
processor may report a Stage 2 translation fault as the result of
Stage 1 fault for load crossing a page boundary when there is a
permission fault or device memory fault at stage 1 and a translation
fault at Stage 2.

So Xen needs to check that Stage 1 translation does not generate a fault
before handling the Stage 2 fault. If it is a Stage 1 translation fault,
return to the guest to let the processor injecting the correct fault.

Only document it as this is already the behavior of the fault handlers.
Note that some optimization could be done to avoid unnecessary translation
fault. This is because HPFAR_EL2 is valid for more use case. For the moment,
the code is left unmodified.

Signed-off-by: Julien Grall 


Actually I am working on a patch series to optimize the data handles 
(i.e to avoid unnecessary translation). I don't think the documentation 
is strictly necessary for now. So I will drop this patch and implement 
the workaround on top of the other series.


Regards,

--
Julien Grall

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

[Xen-devel] [PATCH 7/8] xen/mm: Introduce max_gfn and min_gfn

[Julien Grall]

Those helpers will be useful to find the maximum/minimum between two
GFNs without having to unbox/box manually.

Signed-off-by: Julien Grall 

---
Cc: Stefano Stabellini 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Konrad Rzeszutek Wilk 
Cc: Tim Deegan 
Cc: Wei Liu 
---
 xen/include/xen/mm.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h
index a22c4c2..6fddb6f 100644
--- a/xen/include/xen/mm.h
+++ b/xen/include/xen/mm.h
@@ -70,6 +70,9 @@ TYPE_SAFE(unsigned long, gfn);
 #undef gfn_t
 #endif
 
+#define max_gfn(x, y) _gfn(max(gfn_x(x), gfn_x(y)))
+#define min_gfn(x, y) _gfn(min(gfn_x(x), gfn_x(y)))
+
 TYPE_SAFE(unsigned long, pfn);
 #define PRI_pfn  "05lx"
 #define INVALID_PFN  (~0UL)
-- 
1.9.1


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

[Xen-devel] [PATCH 8/8] xen/arm: p2m_cache_flush: Use the correct terminology and typesafe gfn

[Julien Grall]

p2m_cache_flush is expecting GFNs in parameter and not MFNs. Rename
the variable to *gfn* and use typesafe to avoid possible misusage.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/domctl.c |  2 +-
 xen/arch/arm/p2m.c| 10 +-
 xen/include/asm-arm/p2m.h |  2 +-
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c
index 30453d8..b94e97c 100644
--- a/xen/arch/arm/domctl.c
+++ b/xen/arch/arm/domctl.c
@@ -30,7 +30,7 @@ long arch_do_domctl(struct xen_domctl *domctl, struct domain 
*d,
 if ( e < s )
 return -EINVAL;
 
-return p2m_cache_flush(d, s, e);
+return p2m_cache_flush(d, _gfn(s), _gfn(e));
 }
 case XEN_DOMCTL_bind_pt_irq:
 {
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 135d032..d50eda3 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1467,16 +1467,16 @@ int relinquish_p2m_mapping(struct domain *d)
   d->arch.p2m.default_access);
 }
 
-int p2m_cache_flush(struct domain *d, xen_pfn_t start_mfn, xen_pfn_t end_mfn)
+int p2m_cache_flush(struct domain *d, gfn_t start_gfn, gfn_t end_gfn)
 {
 struct p2m_domain *p2m = >arch.p2m;
 
-start_mfn = MAX(start_mfn, p2m->lowest_mapped_gfn);
-end_mfn = MIN(end_mfn, p2m->max_mapped_gfn);
+start_gfn = max_gfn(start_gfn, _gfn(p2m->lowest_mapped_gfn));
+end_gfn = min_gfn(end_gfn, _gfn(p2m->max_mapped_gfn));
 
 return apply_p2m_changes(d, CACHEFLUSH,
- pfn_to_paddr(start_mfn),
- pfn_to_paddr(end_mfn),
+ pfn_to_paddr(gfn_x(start_gfn)),
+ pfn_to_paddr(gfn_x(end_gfn)),
  pfn_to_paddr(INVALID_MFN),
  MATTR_MEM, 0, p2m_invalid,
  d->arch.p2m.default_access);
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index f204482..03a5cce 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -139,7 +139,7 @@ void p2m_dump_info(struct domain *d);
 mfn_t p2m_lookup(struct domain *d, gfn_t gfn, p2m_type_t *t);
 
 /* Clean & invalidate caches corresponding to a region of guest address space 
*/
-int p2m_cache_flush(struct domain *d, xen_pfn_t start_mfn, xen_pfn_t end_mfn);
+int p2m_cache_flush(struct domain *d, gfn_t start_gfn, gfn_t end_gfn);
 
 /* Setup p2m RAM mapping for domain d from start-end. */
 int p2m_populate_ram(struct domain *d, paddr_t start, paddr_t end);
-- 
1.9.1


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

[Xen-devel] [PATCH 0/8] xen/arm: Use the typesafes gfn and mfn

[Julien Grall]

Hello all,

Some of the ARM functions are mixing gfn vs mfn and even physical vs frame.

To avoid more confusion, this patch series makes use of the terminology
described in xen/include/xen/mm.h and the associated typesafe.

This series is based on staging + the branch next-4.8 from Stefano merge.

I have pushed a branch with the prerequisites and this series on xenbits:
git://xenbits.xen.org/people/julieng/xen-unstable.git branch typesafe-v1

Yours sincerely,

Cc: Stefano Stabellini 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Paul Durrant 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Konrad Rzeszutek Wilk 
Cc: Tim Deegan 
Cc: Wei Liu 

Julien Grall (8):
  xen/arm: Rename gmfn_to_mfn to gfn_to_mfn and use gfn/mfn typesafe
  xen: Use typesafe gfn/mfn in guest_physmap_* helpers
  xen: Use typesafe gfn in xenmem_add_to_physmap_one
  xen/arm: Rename grant_table_gfpn into grant_table_gfn and use the
typesafe gfn
  xen: Use the typesafe mfn and gfn in map_mmio_regions...
  xen/arm: Rework the interface of p2m_lookup and use typesafe gfn and
mfn
  xen/mm: Introduce max_gfn and min_gfn
  xen/arm: p2m_cache_flush: Use the correct terminology and typesafe gfn

 xen/arch/arm/domain.c  |  4 +-
 xen/arch/arm/domain_build.c|  6 +--
 xen/arch/arm/domctl.c  |  2 +-
 xen/arch/arm/gic-v2.c  |  4 +-
 xen/arch/arm/mm.c  | 18 
 xen/arch/arm/p2m.c | 91 --
 xen/arch/arm/platforms/exynos5.c   |  8 ++--
 xen/arch/arm/platforms/omap5.c | 16 +++
 xen/arch/arm/traps.c   | 21 -
 xen/arch/arm/vgic-v2.c |  4 +-
 xen/arch/x86/domain.c  |  5 ++-
 xen/arch/x86/domain_build.c|  6 +--
 xen/arch/x86/hvm/ioreq.c   |  8 ++--
 xen/arch/x86/mm.c  | 21 -
 xen/arch/x86/mm/p2m.c  | 50 -
 xen/common/domctl.c|  4 +-
 xen/common/grant_table.c   | 11 ++---
 xen/common/memory.c| 40 +
 xen/drivers/passthrough/arm/smmu.c |  4 +-
 xen/include/asm-arm/domain.h   |  2 +-
 xen/include/asm-arm/grant_table.h  |  2 +-
 xen/include/asm-arm/p2m.h  | 23 +-
 xen/include/asm-x86/p2m.h  | 11 +++--
 xen/include/xen/mm.h   |  7 ++-
 xen/include/xen/p2m-common.h   |  8 ++--
 25 files changed, 198 insertions(+), 178 deletions(-)

-- 
1.9.1


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

[Xen-devel] [PATCH 2/8] xen: Use typesafe gfn/mfn in guest_physmap_* helpers

[Julien Grall]

Also rename some variables to gfn or mfn when it does not require much
rework.

Signed-off-by: Julien Grall 

---
Cc: Stefano Stabellini 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Paul Durrant 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Konrad Rzeszutek Wilk 
Cc: Tim Deegan 
Cc: Wei Liu 
---
 xen/arch/arm/domain_build.c|  2 +-
 xen/arch/arm/mm.c  | 10 +-
 xen/arch/arm/p2m.c | 20 ++--
 xen/arch/x86/domain.c  |  5 +++--
 xen/arch/x86/domain_build.c|  6 +++---
 xen/arch/x86/hvm/ioreq.c   |  8 
 xen/arch/x86/mm.c  | 12 +++-
 xen/arch/x86/mm/p2m.c  | 32 
 xen/common/grant_table.c   |  7 ---
 xen/common/memory.c| 32 +---
 xen/drivers/passthrough/arm/smmu.c |  4 ++--
 xen/include/asm-arm/p2m.h  | 12 ++--
 xen/include/asm-x86/p2m.h  | 11 +--
 xen/include/xen/mm.h   |  2 +-
 14 files changed, 88 insertions(+), 75 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 2e4c295..02b4539 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -125,7 +125,7 @@ static bool_t insert_11_bank(struct domain *d,
 goto fail;
 }
 
-res = guest_physmap_add_page(d, spfn, spfn, order);
+res = guest_physmap_add_page(d, _gfn(spfn), _mfn(spfn), order);
 if ( res )
 panic("Failed map pages to DOM0: %d", res);
 
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 2ec211b..5ab9b75 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -1153,7 +1153,7 @@ int xenmem_add_to_physmap_one(
 }
 
 /* Map at new location. */
-rc = guest_physmap_add_entry(d, gpfn, mfn, 0, t);
+rc = guest_physmap_add_entry(d, _gfn(gpfn), _mfn(mfn), 0, t);
 
 /* If we fail to add the mapping, we need to drop the reference we
  * took earlier on foreign pages */
@@ -1282,8 +1282,8 @@ int create_grant_host_mapping(unsigned long addr, 
unsigned long frame,
 if ( flags & GNTMAP_readonly )
 t = p2m_grant_map_ro;
 
-rc = guest_physmap_add_entry(current->domain, addr >> PAGE_SHIFT,
- frame, 0, t);
+rc = guest_physmap_add_entry(current->domain, _gfn(addr >> PAGE_SHIFT),
+ _mfn(frame), 0, t);
 
 if ( rc )
 return GNTST_general_error;
@@ -1294,13 +1294,13 @@ int create_grant_host_mapping(unsigned long addr, 
unsigned long frame,
 int replace_grant_host_mapping(unsigned long addr, unsigned long mfn,
 unsigned long new_addr, unsigned int flags)
 {
-unsigned long gfn = (unsigned long)(addr >> PAGE_SHIFT);
+gfn_t gfn = _gfn(addr >> PAGE_SHIFT);
 struct domain *d = current->domain;
 
 if ( new_addr != 0 || (flags & GNTMAP_contains_pte) )
 return GNTST_general_error;
 
-guest_physmap_remove_page(d, gfn, mfn, 0);
+guest_physmap_remove_page(d, gfn, _mfn(mfn), 0);
 
 return GNTST_okay;
 }
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 867e294..decec0d 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1290,26 +1290,26 @@ int map_dev_mmio_region(struct domain *d,
 }
 
 int guest_physmap_add_entry(struct domain *d,
-unsigned long gpfn,
-unsigned long mfn,
+gfn_t gfn,
+mfn_t mfn,
 unsigned long page_order,
 p2m_type_t t)
 {
 return apply_p2m_changes(d, INSERT,
- pfn_to_paddr(gpfn),
- pfn_to_paddr(gpfn + (1 << page_order)),
- pfn_to_paddr(mfn), MATTR_MEM, 0, t,
+ pfn_to_paddr(gfn_x(gfn)),
+ pfn_to_paddr(gfn_x(gfn) + (1 << page_order)),
+ pfn_to_paddr(mfn_x(mfn)), MATTR_MEM, 0, t,
  d->arch.p2m.default_access);
 }
 
 void guest_physmap_remove_page(struct domain *d,
-   unsigned long gpfn,
-   unsigned long mfn, unsigned int page_order)
+   gfn_t gfn,
+   mfn_t mfn, unsigned int page_order)
 {
 apply_p2m_changes(d, REMOVE,
-  pfn_to_paddr(gpfn),
-  pfn_to_paddr(gpfn + (1<

[Xen-devel] [PATCH 4/8] xen/arm: Rename grant_table_gfpn into grant_table_gfn and use the typesafe gfn

[Julien Grall]

The correct acronym for a guest physical frame is gfn. Also use
the typesafe gfn to ensure that a guest frame is effectively used.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/domain.c | 4 ++--
 xen/arch/arm/mm.c | 2 +-
 xen/include/asm-arm/domain.h  | 2 +-
 xen/include/asm-arm/grant_table.h | 2 +-
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 1365b4a..008747c 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -444,13 +444,13 @@ struct domain *alloc_domain_struct(void)
 return NULL;
 
 clear_page(d);
-d->arch.grant_table_gpfn = xzalloc_array(xen_pfn_t, max_grant_frames);
+d->arch.grant_table_gfn = xzalloc_array(gfn_t, max_grant_frames);
 return d;
 }
 
 void free_domain_struct(struct domain *d)
 {
-xfree(d->arch.grant_table_gpfn);
+xfree(d->arch.grant_table_gfn);
 free_xenheap_page(d);
 }
 
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 6882d54..0e408f8 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -1082,7 +1082,7 @@ int xenmem_add_to_physmap_one(
 return -EINVAL;
 }
 
-d->arch.grant_table_gpfn[idx] = gfn_x(gfn);
+d->arch.grant_table_gfn[idx] = gfn;
 
 t = p2m_ram_rw;
 
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 370cdeb..979f7de 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -51,7 +51,7 @@ struct arch_domain
 uint64_t vttbr;
 
 struct hvm_domain hvm_domain;
-xen_pfn_t *grant_table_gpfn;
+gfn_t *grant_table_gfn;
 
 struct vmmio vmmio;
 
diff --git a/xen/include/asm-arm/grant_table.h 
b/xen/include/asm-arm/grant_table.h
index 5e076cc..46cfe24 100644
--- a/xen/include/asm-arm/grant_table.h
+++ b/xen/include/asm-arm/grant_table.h
@@ -30,7 +30,7 @@ static inline int replace_grant_supported(void)
 
 #define gnttab_shared_gmfn(d, t, i)  \
 ( ((i >= nr_grant_frames(d->grant_table)) && \
- (i < max_grant_frames)) ? 0 : (d->arch.grant_table_gpfn[i]))
+ (i < max_grant_frames)) ? 0 : gfn_x((d->arch.grant_table_gfn[i])))
 
 #define gnttab_need_iommu_mapping(d)\
 (is_domain_direct_mapped(d) && need_iommu(d))
-- 
1.9.1


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

[Xen-devel] [PATCH 6/8] xen/arm: Rework the interface of p2m_lookup and use typesafe gfn and mfn

[Julien Grall]

The prototype and the declaration of p2m_lookup disagree on how the
function should be used. One expect a frame number whilst the other
an address.

Thankfully, everyone is using with an address today. However, most of
the callers have to convert a guest frame to an address. Modify
the interface to take a guest physical frame in parameter and return
a machine frame.

Whilst modifying the interface, use typesafe gfn and mfn for clarity
and catching possible misusage.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/p2m.c| 37 -
 xen/arch/arm/traps.c  | 21 +++--
 xen/include/asm-arm/p2m.h |  7 +++
 3 files changed, 34 insertions(+), 31 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 4831cf1..135d032 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -140,14 +140,15 @@ void flush_tlb_domain(struct domain *d)
 }
 
 /*
- * Lookup the MFN corresponding to a domain's PFN.
+ * Lookup the MFN corresponding to a domain's GFN.
  *
  * There are no processor functions to do a stage 2 only lookup therefore we
  * do a a software walk.
  */
-static paddr_t __p2m_lookup(struct domain *d, paddr_t paddr, p2m_type_t *t)
+static mfn_t __p2m_lookup(struct domain *d, gfn_t gfn, p2m_type_t *t)
 {
 struct p2m_domain *p2m = >arch.p2m;
+const paddr_t paddr = pfn_to_paddr(gfn_x(gfn));
 const unsigned int offsets[4] = {
 zeroeth_table_offset(paddr),
 first_table_offset(paddr),
@@ -158,7 +159,7 @@ static paddr_t __p2m_lookup(struct domain *d, paddr_t 
paddr, p2m_type_t *t)
 ZEROETH_MASK, FIRST_MASK, SECOND_MASK, THIRD_MASK
 };
 lpae_t pte, *map;
-paddr_t maddr = INVALID_PADDR;
+mfn_t mfn = _mfn(INVALID_MFN);
 paddr_t mask = 0;
 p2m_type_t _t;
 unsigned int level, root_table;
@@ -216,21 +217,22 @@ static paddr_t __p2m_lookup(struct domain *d, paddr_t 
paddr, p2m_type_t *t)
 {
 ASSERT(mask);
 ASSERT(pte.p2m.type != p2m_invalid);
-maddr = (pte.bits & PADDR_MASK & mask) | (paddr & ~mask);
+mfn = _mfn(paddr_to_pfn((pte.bits & PADDR_MASK & mask) |
+(paddr & ~mask)));
 *t = pte.p2m.type;
 }
 
 err:
-return maddr;
+return mfn;
 }
 
-paddr_t p2m_lookup(struct domain *d, paddr_t paddr, p2m_type_t *t)
+mfn_t p2m_lookup(struct domain *d, gfn_t gfn, p2m_type_t *t)
 {
-paddr_t ret;
+mfn_t ret;
 struct p2m_domain *p2m = >arch.p2m;
 
 spin_lock(>lock);
-ret = __p2m_lookup(d, paddr, t);
+ret = __p2m_lookup(d, gfn, t);
 spin_unlock(>lock);
 
 return ret;
@@ -493,8 +495,9 @@ static int __p2m_get_mem_access(struct domain *d, gfn_t gfn,
  * No setting was found in the Radix tree. Check if the
  * entry exists in the page-tables.
  */
-paddr_t maddr = __p2m_lookup(d, gfn_x(gfn) << PAGE_SHIFT, NULL);
-if ( INVALID_PADDR == maddr )
+mfn_t mfn = __p2m_lookup(d, gfn, NULL);
+
+if ( mfn_x(mfn) == INVALID_MFN )
 return -ESRCH;
 
 /* If entry exists then its rwx. */
@@ -1481,8 +1484,7 @@ int p2m_cache_flush(struct domain *d, xen_pfn_t 
start_mfn, xen_pfn_t end_mfn)
 
 mfn_t gfn_to_mfn(struct domain *d, gfn_t gfn)
 {
-paddr_t p = p2m_lookup(d, pfn_to_paddr(gfn_x(gfn)), NULL);
-return _mfn(p >> PAGE_SHIFT);
+return p2m_lookup(d, gfn, NULL);
 }
 
 /*
@@ -1496,7 +1498,7 @@ p2m_mem_access_check_and_get_page(vaddr_t gva, unsigned 
long flag)
 {
 long rc;
 paddr_t ipa;
-unsigned long maddr;
+gfn_t gfn;
 unsigned long mfn;
 xenmem_access_t xma;
 p2m_type_t t;
@@ -1506,11 +1508,13 @@ p2m_mem_access_check_and_get_page(vaddr_t gva, unsigned 
long flag)
 if ( rc < 0 )
 goto err;
 
+gfn = _gfn(paddr_to_pfn(ipa));
+
 /*
  * We do this first as this is faster in the default case when no
  * permission is set on the page.
  */
-rc = __p2m_get_mem_access(current->domain, _gfn(paddr_to_pfn(ipa)), );
+rc = __p2m_get_mem_access(current->domain, gfn, );
 if ( rc < 0 )
 goto err;
 
@@ -1559,11 +1563,10 @@ p2m_mem_access_check_and_get_page(vaddr_t gva, unsigned 
long flag)
  * We had a mem_access permission limiting the access, but the page type
  * could also be limiting, so we need to check that as well.
  */
-maddr = __p2m_lookup(current->domain, ipa, );
-if ( maddr == INVALID_PADDR )
+mfn = mfn_x(__p2m_lookup(current->domain, gfn, ));
+if ( mfn == INVALID_MFN )
 goto err;
 
-mfn = maddr >> PAGE_SHIFT;
 if ( !mfn_valid(mfn) )
 goto err;
 
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index aa3e3c2..f1737e4 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2318,14 +2318,16 @@ void dump_guest_s1_walk(struct domain *d, vaddr_t addr)
 {
 register_t ttbcr = READ_SYSREG(TCR_EL1);
 uint64_t ttbr0 = READ_SYSREG64(TTBR0_EL1);
-paddr_t