Re: [Xen-devel] [PATCH v8 08/24] x86: refactor psr: set value: implement framework.

[Yi Sun]

On 17-03-08 09:07:10, Jan Beulich wrote:
[...]
> >  /* Called with domain lock held, no extra lock needed for 'psr_cos_ids' */
> >  static void psr_free_cos(struct domain *d)
> >  {
> > -if( !d->arch.psr_cos_ids )
> > +unsigned int socket, cos;
> > +
> > +if ( !d->arch.psr_cos_ids )
> >  return;
> 
> As in an earlier patch I've asked for this check to be removed, I
> think you will need to add a check on socket_info to be non-
> NULL somewhere in this function.
> 
d->arch.psr_cos_ids is used in the loop below. Shall I not check it?
 
> > +for ( socket = 0; socket < nr_sockets; socket++ )
> > +{
> > +struct psr_socket_info *info;
> > +
> > +/* cos 0 is default one which does not need be handled. */
> > +if ( (cos = d->arch.psr_cos_ids[socket]) == 0 )
Here.

> > +continue;
> > +

BRs,
Sun Yi

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt15 guest-start/debian.repeat fail REGR. vs. 106562

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

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

version targeted for testing:
 libvirt  c27020dd4f6ddb9ef5354e75dc7005a5efafe536
baseline version:
 libvirt  b2e5de96c7f3347c2463ca96932e9f4719be2a45

Last test of basis   106562  2017-03-09 04:21:54 Z1 days
Testing same since   106583  2017-03-10 04:20:35 Z0 days1 attempts


People who touched revisions under test:
  Pavel Hrdina 
  Roman Bogorodskiy 

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



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

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

Explanation of these reports, and of 

Re: [Xen-devel] [PATCH V2] x86/altp2m: Added xc_altp2m_set_mem_access_multi()

[Jan Beulich]

>>> On 09.03.17 at 18:29,  wrote:
> On Thu, Mar 9, 2017 at 9:56 AM, Jan Beulich  wrote:
>> However - is this interface supposed to be usable by a guest on itself?
>> Arguably the same question would apply to some of the other sub-ops
>> too, but anyway.
> 
> AFAIK the only op the guest would use on itself is
> HVMOP_altp2m_vcpu_enable_notify.

Which then means we should move all of them out of here, into a
suitable domctl. That will in turn reduce the scope of the bogus
interface versioning, which Andrew did point out, quite a bit.

Jan


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

[Xen-devel] [PATCH v1] boot allocator: Use arch helper for virt_to_mfn on DIRECTMAP

[vijay . kilari]

From: Vijaya Kumar K 

On ARM, virt_to_mfn uses the hardware for address
translation. So if the virtual address is not mapped translation
fault is raised.
On ARM with NUMA, While initializing second memory node,
panic is triggered from init_node_heap() when virt_to_mfn()
is called for DIRECTMAP_VIRT region address.

The init_node_heap() makes a check on MFN passed to ensure that
MFN less than max MFN. For this, check is made against virt_to_mfn of
DIRECTMAP_VIRT_END region. Since DIRECMAP_VIRT region is not mapped
to any physical memory on ARM, it fails.

In this patch, instead of calling virt_to_mfn(), arch helper
arch_directmap_virt_to_mfn() is introduced. For ARM this arch helper
will return 0 and for x86 this helper does virt_to_mfn.

Signed-off-by: Vijaya Kumar K 
---
 xen/common/page_alloc.c| 8 ++--
 xen/include/asm-arm/mm.h   | 8 
 xen/include/asm-x86/page.h | 9 +
 3 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 42c20cb..c69a678 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -533,8 +533,12 @@ static unsigned long init_node_heap(int node, unsigned 
long mfn,
 needed = 0;
 }
 #ifdef DIRECTMAP_VIRT_END
+/*
+ * DIRECTMAP_VIRT is not mapped by all architectures.
+ * Use arch specific for virt_to_mfn on DIRECTMAP memory.
+ */
 else if ( *use_tail && nr >= needed &&
-  (mfn + nr) <= (virt_to_mfn(eva - 1) + 1) &&
+  (mfn + nr) <= (arch_directmap_virt_to_mfn(eva - 1) + 1) &&
   (!xenheap_bits ||
!((mfn + nr - 1) >> (xenheap_bits - PAGE_SHIFT))) )
 {
@@ -543,7 +547,7 @@ static unsigned long init_node_heap(int node, unsigned long 
mfn,
   PAGE_SIZE - sizeof(**avail) * NR_ZONES;
 }
 else if ( nr >= needed &&
-  (mfn + needed) <= (virt_to_mfn(eva - 1) + 1) &&
+  (mfn + needed) <= (arch_directmap_virt_to_mfn(eva - 1) + 1) &&
   (!xenheap_bits ||
!((mfn + needed - 1) >> (xenheap_bits - PAGE_SHIFT))) )
 {
diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
index 60ccbf3..aa34c7a 100644
--- a/xen/include/asm-arm/mm.h
+++ b/xen/include/asm-arm/mm.h
@@ -260,6 +260,14 @@ static inline int gvirt_to_maddr(vaddr_t va, paddr_t *pa, 
unsigned int flags)
 #define virt_to_mfn(va)   (virt_to_maddr(va) >> PAGE_SHIFT)
 #define mfn_to_virt(mfn)  (maddr_to_virt((paddr_t)(mfn) << PAGE_SHIFT))
 
+/*
+ * ARM does not map DIRECTMAP_VIRT to physical memory.
+ * Hence return 0.
+ */
+static inline unsigned long arch_directmap_virt_to_mfn(unsigned long va)
+{
+return 0;
+}
 
 /* Convert between Xen-heap virtual addresses and page-info structures. */
 static inline struct page_info *virt_to_page(const void *v)
diff --git a/xen/include/asm-x86/page.h b/xen/include/asm-x86/page.h
index 46faffc..10c19c1 100644
--- a/xen/include/asm-x86/page.h
+++ b/xen/include/asm-x86/page.h
@@ -374,6 +374,15 @@ perms_strictly_increased(uint32_t old_flags, uint32_t 
new_flags)
 return ((of | (of ^ nf)) == nf);
 }
 
+/*
+ * x86 map DIRECTMAP_VIRT to physical memory. Get the mfn for directmap
+ * memory region.
+ */
+static inline unsigned long arch_directmap_virt_to_mfn(unsigned long va)
+{
+return virt_to_mfn(va);
+}
+
 #endif /* !__ASSEMBLY__ */
 
 #define PAGE_ALIGN(x) (((x) + PAGE_SIZE - 1) & PAGE_MASK)
-- 
2.7.4


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

Re: [Xen-devel] [PATCH V2] x86/altp2m: Added xc_altp2m_set_mem_access_multi()

[Jan Beulich]

>>> On 09.03.17 at 18:15,  wrote:
> On 03/09/2017 06:56 PM, Jan Beulich wrote:
> On 09.03.17 at 10:38,  wrote:
>>> @@ -4535,6 +4536,30 @@ static int do_altp2m_op(
>>>  a.u.set_mem_access.view);
>>>  break;
>>>  
>>> +case HVMOP_altp2m_set_mem_access_multi:
>>> +if ( a.u.set_mem_access_multi.pad ||
>>> + a.u.set_mem_access_multi.opaque >= 
>>> a.u.set_mem_access_multi.nr 
> )
>>> +{
>>> +rc = -EINVAL;
>>> +break;
>>> +}
>>> +rc = p2m_set_mem_access_multi(d, a.u.set_mem_access_multi.pfn_list,
>>> +  a.u.set_mem_access_multi.access_list,
>>> +  a.u.set_mem_access_multi.nr,
>>> +  a.u.set_mem_access_multi.opaque,
>>> +  MEMOP_CMD_MASK,
>>> +  a.u.set_mem_access_multi.view);
>>> +if ( rc > 0 )
>>> +{
>>> +a.u.set_mem_access_multi.opaque = rc;
>>> +if ( __copy_to_guest(arg, , 1) )
>>> +rc = -EFAULT;
>>> +else
>>> +rc = hypercall_create_continuation(__HYPERVISOR_hvm_op, 
> "lh",
>>> +   HVMOP_altp2m, arg);
>>> +}
>>> +break;
>> 
>> Okay, so this is a hvmop, in which case I'm fine with the continuation
>> model used.
>> 
>> However - is this interface supposed to be usable by a guest on itself?
>> Arguably the same question would apply to some of the other sub-op
>> too, but anyway.
> 
> Not for any of our use cases. The whole point is for dom0 (or another
> suitably privileged domain) to monitor another guest that consequently
> can't, by design, evade detection of bad behaviour by acting at a higher
> privilege level than the protection software. It wouldn't make sense for
> a domain to be doing this on itself.

In which case this should be a domctl.

>>> --- a/xen/include/public/hvm/hvm_op.h
>>> +++ b/xen/include/public/hvm/hvm_op.ht
>>> @@ -231,6 +231,23 @@ struct xen_hvm_altp2m_set_mem_access {
>>>  typedef struct xen_hvm_altp2m_set_mem_access 
>>> xen_hvm_altp2m_set_mem_access_t;
>>>  DEFINE_XEN_GUEST_HANDLE(xen_hvm_altp2m_set_mem_access_t);
>>>  
>>> +struct xen_hvm_altp2m_set_mem_access_multi {
>>> +/* view */
>>> +uint16_t view;
>>> +uint16_t pad;
>>> +/* Number of pages */
>>> +uint32_t nr;
>>> +/* Used for continuation purposes */
>>> +uint64_t opaque;
>>> +/* List of pfns to set access for */
>>> +XEN_GUEST_HANDLE(const_uint64) pfn_list;
>>> +/* Corresponding list of access settings for pfn_list */
>>> +XEN_GUEST_HANDLE(const_uint8) access_list;
>> 
>> I'm afraid these handles aren't going to work for a 32-bit guest. Note
>> how no other hvmop uses handles.
> 
> Right, I guess I'll have to pass these through the compat code then,
> like the xc_set_mem_access_multi() code does. I'll take a look at what
> that entails.

Which in turn means you don't need to go through the hassles of
this.

Jan


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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-arndale   3 host-install(3)broken REGR. vs. 106534
 test-amd64-amd64-migrupgrade 10 xen-boot/dst_hostfail REGR. vs. 106534
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate/x10 
fail REGR. vs. 106534
 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail REGR. vs. 106534

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 106534
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 106534
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 106534
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 106534
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 106534
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 106534
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 106534
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 106534

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 build-arm64   5 xen-buildfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 build-arm64-xsm   5 xen-buildfail   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
 build-arm64-pvops 5 kernel-build fail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   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-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 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

version targeted for testing:
 xen  9dc1e0cd81ee469d638d1962a92d9b4bd2972bfa
baseline version:
 xen  4036e7c592905c2292cdeba8269e969959427237

Last test of basis   106534  2017-03-07 19:14:51 Z2 days
Failing since106547  2017-03-08 08:59:30 Z1 days4 attempts
Testing same since   106580  2017-03-09 23:15:02 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Christoph Egger 
  George Dunlap 

Re: [Xen-devel] [PATCH v8 18/24] x86: L2 CAT: implement get hw info flow.

[Yi Sun]

On 17-03-09 08:13:59, Jan Beulich wrote:
> >>> On 15.02.17 at 09:49,  wrote:
> > +static bool l2_cat_get_feat_info(const struct feat_node *feat,
> > + uint32_t data[], uint32_t array_len)
> > +{
> > +if ( !data || 2 > array_len )
> > +return false;
> > +
> > +data[CBM_LEN] = feat->info.l2_cat_info.cbm_len;
> > +data[COS_MAX] = feat->info.l2_cat_info.cos_max;
> 
> What about PSR_FLAG? Which puts under question the
> array_len check at the start of this and its sibling functions: If
> more array entries are provided, they'd all be left uninitialized
> without the caller having a way to know. Coming back to the
> data structures being the same for all features, there should
> presumably be a structure instead of an array be used for
> communication here, and ...
> 
> > @@ -754,6 +755,11 @@ struct xen_sysctl_psr_cat_op {
> >  #define XEN_SYSCTL_PSR_CAT_L3_CDP   (1u << 0)
> >  uint32_t flags; /* OUT: CAT flags */
> >  } l3_info;
> > +
> > +struct {
> > +uint32_t cbm_len;   /* OUT: CBM length */
> > +uint32_t cos_max;   /* OUT: Maximum COS */
> > +} l2_info;
> 
> ... this should use the same structure as l3_info (flags being
> set to zero until a use arises). This would then also allow for
> more code to be shared instead of duplicated.
> 
Ok, will reuse l3_info for L2 CAT. May modify its name to cat_info.

But for MBA or future feature, its info is different with CAT. So, it may
not be approriate to use a structure as parameter for 'psr_get_info'.
So I would prefer to keep data[]. Of course, I will correct array_len check
per Roger's suggestion, like "array_len != PSR_INFO_SIZE". Is that good to
you?

> Jan

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

Re: [Xen-devel] [PATCH v8 17/24] x86: L2 CAT: implement CPU init and free flow.

[Yi Sun]

On 17-03-09 08:04:35, Jan Beulich wrote:
> >>> On 15.02.17 at 09:49,  wrote:
> > @@ -684,6 +686,53 @@ struct feat_ops l3_cdp_ops = {
> >  .write_msr = l3_cdp_write_msr,
> >  };
> >  
> > +/* L2 CAT callback functions implementation. */
> > +static void l2_cat_init_feature(struct cpuid_leaf regs,
> 
> const struct cpuid_leaf * (and of course I should have noticed this
> already in earlier patches, but I didn't)
> 
Will fixed this from beginning.

> > +struct feat_node *feat,
> > +struct psr_socket_info *info)
> > +{
> > +struct psr_cat_hw_info l2_cat = { };
> 
> I realize Konrad did ask for the initializer here, but it's really pointless
> to have such when both structure fields get very obviously set right
> below. If you want an initializer, just set the fields to their final values.
> 
Got it. Thanks!

> > +unsigned int socket;
> > +
> > +/* No valid values so do not enable the feature. */
> > +if ( !regs.a || !regs.d )
> > +return;
> > +
> > +l2_cat.cbm_len = (regs.a & CAT_CBM_LEN_MASK) + 1;
> > +l2_cat.cos_max = min(opt_cos_max, regs.d & CAT_COS_MAX_MASK);
> > +
> > +/* cos=0 is reserved as default cbm(all ones). */
> > +feat->cos_reg_val[0] = (1ull << l2_cat.cbm_len) - 1;
> > +
> > +feat->feature = PSR_SOCKET_L2_CAT;
> > +ASSERT(!test_bit(PSR_SOCKET_L2_CAT, >feat_mask));
> > +__set_bit(PSR_SOCKET_L2_CAT, >feat_mask);
> > +
> > +feat->info.l2_cat_info = l2_cat;
> > +
> > +info->nr_feat++;
> 
> Is this field really used for anything? I don't recall seeing other than
> these increments.
> 
Just for a record. Will remove it.

> Jan

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

Re: [Xen-devel] [PATCH v8 13/24] x86: refactor psr: implement CPU init and free flow for CDP.

[Yi Sun]

On 17-03-09 07:53:16, Jan Beulich wrote:
> >>> On 15.02.17 at 09:49,  wrote:
> > --- a/xen/arch/x86/psr.c
> > +++ b/xen/arch/x86/psr.c
> > @@ -97,6 +97,7 @@ struct psr_cat_hw_info {
> >  struct feat_hw_info {
> >  union {
> >  struct psr_cat_hw_info l3_cat_info;
> > +struct psr_cat_hw_info l3_cdp_info;
> 
> Two union members of the same type? What's the union good for
> then? (I've peeked ahead, and L2 CAT adds yet another one. A
> strong sign that you've gone too far with what needs to be per-
> feature vs what can be common.)
> 
I have corrected this. L3 CAT/CDP and L2 CAT will use a common HW info
in next version.

> > @@ -195,6 +196,22 @@ struct feat_node {
> >  struct list_head list;
> >  };
> >  
> > +/*
> > + * get_data - get DATA COS register value from input COS ID.
> > + * @feat:the feature list entry.
> > + * @cos: the COS ID.
> > + */
> > +#define get_cdp_data(feat, cos)  \
> > +( feat->cos_reg_val[cos * 2] )
> 
> Stray blanks inside parentheses. Macro parameters need to be
> parenthesized.
> 
It has been corrected in next version per Roger's comment.

[...]
> > @@ -1267,6 +1351,14 @@ static int psr_cpu_prepare(void)
> >   (feat_l3_cat = xzalloc(struct feat_node)) == NULL )
> >  return -ENOMEM;
> >  
> > +if ( feat_l3_cdp == NULL &&
> > + (feat_l3_cdp = xzalloc(struct feat_node)) == NULL )
> > +{
> > +xfree(feat_l3_cat);
> > +feat_l3_cat = NULL;
> 
> Why the freeing? We've decided to allow for one node to be kept,
> so no reason to free it on the error path here.
> 
Ok, will correct this.

> Jan

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

Re: [Xen-devel] [PATCH v8 11/24] x86: refactor psr: set value: implement cos id picking flow.

[Yi Sun]

On 17-03-09 07:10:33, Jan Beulich wrote:
> >>> On 15.02.17 at 09:49,  wrote:
> > @@ -397,6 +408,25 @@ static int l3_cat_compare_val(const uint64_t val[],
> >  return 0;
> >  }
> >  
> > +static bool l3_cat_fits_cos_max(const uint64_t val[],
> > +const struct feat_node *feat,
> > +unsigned int cos)
> > +{
> > +uint64_t l3_def_cbm;
> > +
> > +l3_def_cbm = (1ull << feat->info.l3_cat_info.cbm_len) - 1;
> 
> Seeing this pattern recur I wonder whether this also wouldn't be
> something that could be stored once in a generic manner, avoiding
> the need for this per-feature callback (cos_max should be common
> to all features too - not the values, but the abstract notion - so
> perhaps get_cos_max() isn't needed as a callback either).
> 
DYM to create a member in 'struct feat_node'? E.g:
uint64_t def_val;

> >  static int pick_avail_cos(const struct psr_socket_info *info,
> >const uint64_t *val, uint32_t array_len,
> >unsigned int old_cos,
> >enum psr_feat_type feat_type)
> >  {
> > +unsigned int cos;
> > +unsigned int cos_max = 0;
> > +const struct feat_node *feat;
> > +const unsigned int *ref = info->cos_ref;
> > +
> > +/*
> > + * cos_max is the one of the feature which is being set.
> > + */
> 
> This is a single line comment.
> 
> > +list_for_each_entry(feat, >feat_list, list)
> > +{
> > +if ( feat->feature != feat_type )
> > +continue;
> > +
> > +cos_max = feat->ops.get_cos_max(feat);
> > +if ( cos_max > 0 )
> > +break;
> > +}
> 
> I think I've seen this a number of times by now - please make this a
> helper function, or store the result (which isn't going to change
> afaict).
> 
This behavior is changed in next version.

> Other than these comments given to earlier patches apply here too,
> as I think is obvious.
> 
> Jan

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

Re: [Xen-devel] [PATCH v8 10/24] x86: refactor psr: set value: implement cos finding flow.

[Yi Sun]

On 17-03-08 10:03:10, Jan Beulich wrote:
> >>> On 15.02.17 at 09:49,  wrote:
> > Continue with patch:
> 
> ???
> 
> > 'x86: refactor psr: set value: assemble features value array'
> 
> Or did you perhaps mean "continue from"?
> 
Should be 'from'. Thanks!

> > --- a/xen/arch/x86/psr.c
> > +++ b/xen/arch/x86/psr.c
> > @@ -145,6 +145,19 @@ struct feat_ops {
> > const struct feat_node *feat,
> > enum cbm_type type,
> > uint64_t m);
> > +/*
> > + * compare_val is used in set value process to compare if the
> > + * input value array can match all the features' COS registers values
> > + * according to input cos id.
> > + *
> > + * The return value is the amount of entries to skip in the value array
> > + * or error.
> > + * 1 - one entry in value array.
> > + * 2 - two entries in value array, e.g. CDP uses two entries.
> 
> Isn't this get_cos_num()'s result again? Or, looking at the function
> below, is the comment simply stale?
> 
Sorry, forgot to update it.

> > @@ -356,6 +369,34 @@ static int l3_cat_set_new_val(uint64_t val[],
> >  return 0;
> >  }
> >  
> > +static int l3_cat_compare_val(const uint64_t val[],
> > +  const struct feat_node *feat,
> > +  unsigned int cos, bool *found)
> > +{
> > +uint64_t l3_def_cbm;
> > +
> > +l3_def_cbm = (1ull << feat->info.l3_cat_info.cbm_len) - 1;
> 
> Please only calculate the value on the path you need it. Also this
> will again degenerate of cbm_len == 64.
> 
Sorry, what do you mean? I need get the default value of L3 CAT here
to check if input val equals the default one if cos exceeds cos_max.

As explanation in previous patch, cbm_len is not 64. It means how many bits
the CBM value has. E.g. L3 CAT may have 11 bits. L2 CAT may have 8 bits.

> > +/*
> > + * Different features' cos_max are different. If cos id of the feature
> > + * being set exceeds other feature's cos_max, the val of other feature
> > + * must be default value. HW supports such case.
> > + */
> > +if ( cos > feat->info.l3_cat_info.cos_max )
> > +{
> > +if ( val[0] != l3_def_cbm )
> > +{
> > +*found = false;
> > +return -ENOENT;
> 
> What is the difference between this "not found" and ...
> 
This is an error case. If input cos exceeds the cos_max and the input val is
not default value, that means the input parameters exceed HW ability. We should
report error back.

> > +}
> > +*found = true;
> > +}
> > +else
> > +*found = (val[0] == feat->cos_reg_val[cos]);
> > +
> > +return 0;
> 
> ... the possible one here? I.e. why once -ENOENT and once 0 as
> return value?
> 
0 means success. '*found' means if the val is found or not. Per Roger's
suggestion, I will refine this function to use return value to check
if it is found or not.

> > @@ -715,6 +757,57 @@ static int find_cos(const uint64_t *val, uint32_t 
> > array_len,
> >  enum psr_feat_type feat_type,
> >  const struct psr_socket_info *info)
> >  {
> > +unsigned int cos;
> > +const unsigned int *ref = info->cos_ref;
> > +const struct feat_node *feat;
> > +const uint64_t *val_tmp = val;
> > +int ret;
> > +bool found = false;
> > +unsigned int cos_max = 0;
> > +
> > +/* cos_max is the one of the feature which is being set. */
> > +list_for_each_entry(feat, >feat_list, list)
> > +{
> > +if ( feat->feature != feat_type )
> > +continue;
> > +
> > +cos_max = feat->ops.get_cos_max(feat);
> > +if ( cos_max > 0 )
> 
> What's the purpose of this check? I.e. why do you continue the loop
> in case you find zero? You won't find another node with the same
> feat_type, will you?
> 
This is corrected in next version. Thanks!

> > +break;
> > +}
> > +
> > +for ( cos = 0; cos <= cos_max; cos++ )
> > +{
> > +if ( cos && !ref[cos] )
> > +continue;
> > +
> > +/* Not found, need find again from beginning. */
> 
> You may not even have looked yet, so how can you say "not found"?
> 
Sorry, it should be "If not found, need find again...".

> Jan

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

[Xen-devel] [qemu-mainline test] 106574: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 106559
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 106559
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 106559
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 106559
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 106559
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 106559

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 build-arm64   5 xen-buildfail   never pass
 build-arm64-xsm   5 xen-buildfail   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-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 build-arm64-pvops 5 kernel-build fail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  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-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass

version targeted for testing:
 qemuudd4d2578215cd380f40a38028a9904e15b135ef3
baseline version:
 qemuub64842dee42d6b24d51283e4722140b73be1e222

Last test of basis   106559  2017-03-08 22:14:58 Z1 days
Testing same since   106574  2017-03-09 19:12:40 Z0 days1 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Peter Maydell 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  fail
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  fail
 build-armhf  pass
 build-i386 

Re: [Xen-devel] [early RFC] ARM PCI Passthrough design document

[Roger Pau Monné]

On Thu, Mar 09, 2017 at 07:29:34PM -0500, Konrad Rzeszutek Wilk wrote:
> On Thu, Mar 09, 2017 at 01:26:45PM +, Julien Grall wrote:
> > Hi Konrad,
> > 
> > On 09/03/17 11:17, Konrad Rzeszutek Wilk wrote:
> > > On Thu, Mar 09, 2017 at 11:59:51AM +0900, Roger Pau Monné wrote:
> > > > On Wed, Mar 08, 2017 at 02:12:09PM -0500, Konrad Rzeszutek Wilk wrote:
> > > > > On Wed, Mar 08, 2017 at 07:06:23PM +, Julien Grall wrote:
> > > > > .. this as for SR-IOV devices you need the drivers to kick the 
> > > > > hardware
> > > > > to generate the new bus addresses. And those (along with the BAR 
> > > > > regions) are
> > > > > not visible in ACPI (they are constructued dynamically).
> > > > 
> > > > There's already code in Xen [0] to find out the size of the BARs of 
> > > > SR-IOV
> > > > devices, but I'm not sure what's the intended usage of that, does it 
> > > > need to
> > > > happen _after_ the driver in Dom0 has done whatever magic for this to 
> > > > work?
> > > 
> > > Yes. This is called via the PHYSDEVOP_pci_device_add hypercall when
> > > the device driver in dom0 has finished "creating" the VF. See 
> > > drivers/xen/pci.c
> > 
> > We are thinking to not use PHYSDEVOP_pci_device_add hypercall for ARM and do
> > the PCI scanning in Xen.
> > 
> > If I understand correctly what you said, only the PCI driver will be able to
> > kick SR-IOV device and Xen would not be able to detect the device until it
> > has been fully configured. So it would mean that we have to keep
> > PHYSDEVOP_pci_device_add around to know when Xen can use the device.
> > 
> > Am I correct?
> 
> Yes. Unless the PCI drivers come up with some other way to tell the
> OS that oh, hey, there is this new PCI device with this BDF.
> 
> Or the underlaying bus on ARM can send some 'new device' information?

Hm, is this something standard between all the SR-IOV implementations, or each
vendors have their own sauce?

Would it be possible to do this SR-IOV initialization inside of Xen, or that
requires ACPI information?

Roger.

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

Re: [Xen-devel] [PATCH v8 09/24] x86: refactor psr: set value: assemble features value array.

[Yi Sun]

On 17-03-08 09:54:04, Jan Beulich wrote:
> >>> On 15.02.17 at 09:49,  wrote:
[...]
> > +/*
> > + * get_old_val and set_new_val are a pair of functions called in order.
> > + * The caller will traverse all features in the list and call both
> > + * functions for every feature to do below two things:
> > + * 1. get old_cos register value of all supported features and
> > + * 2. set the new value for the feature.
> 
> This is misleading, I think: I don't think a new value is being set for
> every feature. This should be worded less ambiguously.
> 
The expression is not accurate. I will correct this. Thanks!

> > @@ -207,6 +233,29 @@ static enum psr_feat_type 
> > psr_cbm_type_to_feat_type(enum cbm_type type)
> >  return feat_type;
> >  }
> >  
> > +static bool psr_check_cbm(unsigned int cbm_len, uint64_t cbm)
> > +{
> > +unsigned int first_bit, zero_bit;
> > +
> > +/* Set bits should only in the range of [0, cbm_len). */
> > +if ( cbm & (~0ull << cbm_len) )
> 
> This will not do what you intend for cbm_len == 64.
> 
cbm_len is not 64. cbm_len means the CBM value length, how many bits. For L3
CAT, it may be 11 bits. For L2 CAT, it may be 8 bits.

> > +static int l3_cat_get_old_val(uint64_t val[],
> > +  const struct feat_node *feat,
> > +  unsigned int old_cos)
> > +{
> > +if ( old_cos > feat->info.l3_cat_info.cos_max )
> 
> Afaics this condition is the only L3 CAT specific thing in this function.
> Should more of it be moved into common code? Same below for
> set_new_val.
> 
Sorry, I may not understand your intention. For different features, they have
different cos_max. Do you mean I should abstract a callback function for all
features to handle this cos_max check? Thanks!

> > -static int assemble_val_array(uint64_t *val,
> > +static int combine_val_array(uint64_t *val,
> 
> Same comment as earlier on - please decide for a final name right
> when introducing a function. In fact I'd prefer it to remain
> "assemble".
> 
This is corrected in next version. I will change name back to assemble if you
like it.

> >  {
> > -return -EINVAL;
> > +const struct feat_node *feat;
> > +int ret;
> > +uint64_t *val_tmp = val;
> 
> I don't really see the need for this helper variable. Simply ...
> 
> > +if ( !val )
> > +return -EINVAL;
> > +
> > +/* Get all features current values according to old_cos. */
> > +list_for_each_entry(feat, >feat_list, list)
> > +{
> > +/* value getting order is same as feature list */
> > +ret = feat->ops.get_old_val(val_tmp, feat, old_cos);
> > +if ( ret )
> > +return ret;
> > +
> > +val_tmp += feat->ops.get_cos_num(feat);
> 
> ... use val here, after checking the return value against
> array_len, and the also subtract from array_len. (I am averse
> to _tmp suffixes, I'm sorry.)
> 
Ok, no problem.

> Btw - for any of the later features, does their get_cos_num() ever
> return other than a constant value? If not, there's no point in making
> this a function call - you could simply have a numeric member in the
> structure.
>
Good idea. Thanks!

[...] 

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

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

[osstest service owner]

flight 106572 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106572/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 105963
 test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 105963

version targeted for testing:
 ovmf 78c41ff519b187d8979cda7074f007a6323f9acd
baseline version:
 ovmf e0307a7dad02aa8c0cd8b3b0b9edce8ddb3fef2e

Last test of basis   105963  2017-02-21 21:43:31 Z   16 days
Failing since105980  2017-02-22 10:03:53 Z   15 days   42 attempts
Testing same since   106572  2017-03-09 18:46:04 Z0 days1 attempts


People who touched revisions under test:
  Anthony PERARD 
  Ard Biesheuvel 
  Bi, Dandan 
  Brijesh Singh 
  Chao Zhang 
  Chen A Chen 
  Dandan Bi 
  edk2-devel On Behalf Of rthomaiy <[mailto:edk2-devel-boun...@lists.01.org]>
  Fu Siyuan 
  Hao Wu 
  Hegde Nagaraj P 
  Hess Chen 
  Jeff Fan 
  Jiaxin Wu 
  Jiewen Yao 
  Laszlo Ersek 
  Leo Duran 
  Paolo Bonzini 
  Qin Long 
  Richard Thomaiyar 
  Ruiyu Ni 
  Star Zeng 
  Wu Jiaxin 
  Yonghong Zhu 
  Zhang Lubo 
  Zhang, Chao B 

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



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

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

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

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


Not pushing.

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

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

[Xen-devel] [linux-linus test] 106570: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-pvops   3 host-install(3) broken in 106563 REGR. vs. 59254
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail REGR. vs. 59254
 test-armhf-armhf-xl  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-xsm  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-credit2  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-libvirt-xsm 11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-cubietruck 11 guest-start fail REGR. vs. 59254
 test-armhf-armhf-libvirt 11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-arndale  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-multivcpu 11 guest-start  fail REGR. vs. 59254

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-winxpsp3 17 guest-start/win.repeat fail in 106563 
pass in 106570
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail pass in 
106563

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 11 guest-start   fail REGR. vs. 59254
 test-amd64-amd64-xl-rtds  9 debian-installfail REGR. vs. 59254
 test-armhf-armhf-xl-vhd   9 debian-di-install   fail baseline untested
 test-armhf-armhf-libvirt-raw  9 debian-di-install   fail baseline untested
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 59254
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 59254
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 59254
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 59254

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-multivcpu  1 build-check(1)  blocked in 106563 n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked in 106563 n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked in 106563 n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked in 106563 n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked in 106563 n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked in 106563 n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1) blocked in 106563 n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked in 106563 n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked in 106563 n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked in 106563 n/a
 test-armhf-armhf-xl-xsm   1 build-check(1)   blocked in 106563 n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 build-arm64-xsm   5 xen-buildfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 build-arm64   5 xen-buildfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass

version targeted for testing:
 linuxea6200e84182989a3cce9687cf79a23ac44ec4db
baseline version:
 linux45820c294fe1b1a9df495d57f40585ef2d069a39

Last test of basis59254  2015-07-09 04:20:48 Z  609 days
Failing since 59348  2015-07-10 04:24:05 Z  608 days  323 attempts
Testing same since   106563  2017-03-09 07:17:51 Z0 days2 attempts


8049 people touched revisions under test,
not listing them all

jobs:
 build-amd64-xsm   

Re: [Xen-devel] Xen 4.8.0 dom0pvh=1 causes ext4 filesystem corruption

[Roger Pau Monné]

On Thu, Mar 09, 2017 at 05:13:38PM +0200, Valtteri Kiviniemi wrote:
> Hi,
> 
> Yesterday I decided to upgrade my Xen version from 4.6.0 to 4.8.0. I
> compiled it from source and at the same time I compiled the latest Linux
> kernel (4.10.1).
> 
> When rebooting I decided to try if dom0 PVH would work (with previous Xen
> version it just caused kernel panic). Seemed to boot fine until systemd
> started mounting the root filesystem and then the console was filled with
> ext4 errors. Couldn't even log in.
> 
> Booting with a systemrescuecd and running fsck just caused the whole
> filesystem to be re-attached in thousands of small pieces under lost+found.
> I was sure that this was a some kind of hardware failure, so I switched my
> hard drives and did a clean reinstall for dom0 and tried again. Again,
> after a reboot the whole rootfs was completely corrupted.
> 
> Second reinstall and this time I disabled dom0 PVH and the system booted
> just fine, and no ext4 errors. My root filesystem is just a simple Linux
> software raid1 with ext4 on top of it.
> 
> Now that I started thinking I have also had strange ext4 errors happening
> inside my guests, so I also disabled PVH from all the guests. With guests
> the ext4 error is always the same: "EXT4-fs error (device xvda1):
> ext4_iget:4665: inode #317: comm find: bogus i_mode (135206)"

As Andrew already pointed out, this implementation (PVHv1) is already removed
from Linux, and will be removed soon from Xen. FWIW, FreeBSD has been using
that for Dom0, and no one reported a single FS corruption issue, so it seems
like this was something specific to the Linux PVHv1 implementation.

Roger.

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

[Xen-devel] [PATCH] tools/kdd: remove unneeded packed attributes

[Roger Pau Monne]

The layout of the structures make them already aligned, there's no need for the
packed attributes.

Signed-off-by: Roger Pau Monné 
---
Cc: Tim Deegan 
Cc: Ian Jackson 
Cc: Wei Liu 
---
 tools/debugger/kdd/kdd.h | 44 +---
 1 file changed, 21 insertions(+), 23 deletions(-)

diff --git a/tools/debugger/kdd/kdd.h b/tools/debugger/kdd/kdd.h
index bfb00ba..bb1b1a6 100644
--- a/tools/debugger/kdd/kdd.h
+++ b/tools/debugger/kdd/kdd.h
@@ -37,8 +37,6 @@
 
 #include 
 
-#define PACKED __attribute__((packed))
-
 /*
  * Serial line protocol: Sender sends a 16-byte header with an optional
  * payload following it.  Receiver responds to each packet with an
@@ -69,7 +67,7 @@ typedef struct {
 uint32_t id;  /* Echoed in responses */
 uint32_t sum; /* Unsigned sum of all payload bytes */
 uint8_t payload[0];
-} PACKED kdd_hdr;
+} kdd_hdr;
 
 #define KDD_PKT_CMD 0x0002  /* Debugger commands (and replies to them) */
 #define KDD_PKT_MSG 0x0003  /* Kernel messages for the user */
@@ -122,7 +120,7 @@ typedef struct {
 uint64_t addr;  /* IN: address of start of read/write */
 uint32_t length_req;/* IN: bytes to read/write */
 uint32_t length_rsp;/* OUT: bytes successfully read/written */
-} PACKED kdd_cmd_mem;
+} kdd_cmd_mem;
 
 /* CPU register access.  As for memory accesses, but the data is a
  * fixed-length block of register info. */
@@ -134,7 +132,7 @@ typedef struct {
 uint16_t u1;
 uint16_t cpu;   /* IN: Zero-based processor ID */
 uint32_t status;/* IN: STATUS_PENDING; OUT: result status. */
-} PACKED kdd_cmd_regs;
+} kdd_cmd_regs;
 
 #define KDD_CMD_READ_MSR0x3152  /* "R1" */
 #define KDD_CMD_WRITE_MSR   0x3153  /* "S1" */
@@ -145,7 +143,7 @@ typedef struct {
 uint32_t u2;
 uint32_t msr;   /* IN/OUT: MSR number */
 uint64_t val;   /* IN/OUT: MSR contents */
-} PACKED kdd_cmd_msr;
+} kdd_cmd_msr;
 
 /* Breakpoint commands. */
 
@@ -156,7 +154,7 @@ typedef struct {
 uint32_t status;/* IN: STATUS_PENDING; OUT: result status. */
 uint32_t u2;
 uint32_t bp;/* IN: ID of breakpoint to operate on */
-} PACKED kdd_cmd_soft_bp;
+} kdd_cmd_soft_bp;
 
 #define KDD_CMD_HARD_BP 0x315C  /* "\1" */
 
@@ -169,7 +167,7 @@ typedef struct {
 uint64_t u4;
 uint64_t u5;
 uint64_t u6;
-} PACKED kdd_cmd_hard_bp;
+} kdd_cmd_hard_bp;
 
 /* Flow control commands.  These commands are _not_ responded to.  */
 
@@ -184,7 +182,7 @@ typedef struct {
 uint32_t reason1;   /* IN: KDD_DBG_* */
 uint32_t u2;
 uint64_t reason2;   /* IN: always same as reason1 */
-} PACKED kdd_cmd_cont;
+} kdd_cmd_cont;
 
 /* Handshake command. */
 
@@ -212,7 +210,7 @@ typedef struct {
 int64_t kern_addr;  /* OUT: KernBase */
 int64_t mods_addr;  /* OUT: PsLoadedModuleList */
 int64_t data_addr;  /* OUT: DebuggerDataList */
-} PACKED kdd_cmd_shake;
+} kdd_cmd_shake;
 
 /* Change active CPU.  This command is _not_ responded to */
 
@@ -222,7 +220,7 @@ typedef struct {
 uint16_t u1;
 uint16_t cpu;   /* IN: Zero-based processor ID */
 uint32_t status;/* IN: STATUS_PENDING */
-} PACKED kdd_cmd_setcpu;
+} kdd_cmd_setcpu;
 
 typedef struct {
 uint32_t subtype;   /* IN: KDD_CMD_x */
@@ -238,7 +236,7 @@ typedef struct {
 uint8_t pad[52];
 };
 uint8_t data[0];
-} PACKED kdd_cmd;
+} kdd_cmd;
 
 
 /*
@@ -257,7 +255,7 @@ typedef struct {
 uint32_t length;/* Length in bytes of trailing string */
 uint32_t u2;
 uint8_t string[0];  /* Non-terminated character string */
-} PACKED kdd_msg;
+} kdd_msg;
 
 /* Registry updates (Hive loads?) */
 
@@ -267,7 +265,7 @@ typedef struct {
 uint32_t subtype;   /* KDD_REG_CHANGE */
 uint32_t u1[15];
 uint16_t string[0]; /* Null-terminated wchar string */
-} PACKED kdd_reg;
+} kdd_reg;
 
 /* State changes.  After sending a state-change message the kernel halts
  * until it receives a continue command from the debugger. */
@@ -293,7 +291,7 @@ typedef struct {
 uint32_t u4[2];
 uint32_t ilen;  /* Number of bytes of instruction following */
 uint8_t inst[36];   /* VA contents from %eip onwards */
-} PACKED kdd_stc_stop;
+} kdd_stc_stop;
 
 typedef struct {
 uint32_t u1[3];
@@ -301,7 +299,7 @@ typedef struct {
 uint64_t rip;   /* Instruction pointer, sign-extended */
 uint64_t u3[26];
 uint8_t path[0];/* Null-terminated ASCII path to loaded mod. */
-} PACKED kdd_stc_load;
+} kdd_stc_load;
 
 typedef struct {
 uint32_t 

Re: [Xen-devel] [PATCH v8 08/24] x86: refactor psr: set value: implement framework.

[Yi Sun]

On 17-03-08 09:07:10, Jan Beulich wrote:
> >>> On 15.02.17 at 09:49,  wrote:
> > As set value flow is the most complicated one in psr, it will be
> > divided to some patches to make things clearer. This patch
> > implements the set value framework to show a whole picture firstly.
> > 
> > It also changes domctl interface to make it more general.
> > 
> > To make the set value flow be general and can support multiple features
> > at same time, it includes below steps:
> > 1. Get COS ID of current domain using.
> 
> What is the "using" here supposed to mean?
> 
My meaning is to get the cos id that current domain is using. Sorry for this.
Will make it better.

> > --- a/xen/arch/x86/psr.c
> > +++ b/xen/arch/x86/psr.c
> > @@ -546,18 +546,214 @@ int psr_get_val(struct domain *d, unsigned int 
> > socket,
> >  return psr_get(socket, type, NULL, 0, d, val);
> >  }
> >  
> > -int psr_set_l3_cbm(struct domain *d, unsigned int socket,
> > -   uint64_t cbm, enum cbm_type type)
> > +/* Set value functions */
> > +static unsigned int get_cos_num(const struct psr_socket_info *info)
> >  {
> >  return 0;
> >  }
> >  
> > +static int assemble_val_array(uint64_t *val,
> > +  uint32_t array_len,
> > +  const struct psr_socket_info *info,
> > +  unsigned int old_cos)
> > +{
> > +return -EINVAL;
> > +}
> > +
> > +static int set_new_val_to_array(uint64_t *val,
> 
> insert_new_val() ? And when talking about arrays, as indicated
> before, please use [] notation instead of pointers. This is
> particularly relevant when the function name suggests that it
> would be "val" which gets inserted, but aiui it is really ...
> 
> > +uint32_t array_len,
> > +const struct psr_socket_info *info,
> > +enum psr_feat_type feat_type,
> > +enum cbm_type type,
> > +uint64_t m)
> 
> ... "m". Therefore please also consider better naming of parameters.
> 
Sure, thanks!

> > +static int write_psr_msr(unsigned int socket, unsigned int cos,
> > + const uint64_t *val)
> > +{
> > +return -ENOENT;
> > +}
> 
> Is this function intended you write just one MSR, or potentially many?
> In the latter case the name would perhaps better be "write_psr_msrs()".
> 
For one feature, it does set one MSR.

> > +int psr_set_val(struct domain *d, unsigned int socket,
> > +uint64_t val, enum cbm_type type)
> > +{
> > +unsigned int old_cos;
> > +int cos, ret;
> > +unsigned int *ref;
> > +uint64_t *val_array;
> > +struct psr_socket_info *info = get_socket_info(socket);
> > +uint32_t array_len;
> > +enum psr_feat_type feat_type;
> > +
> > +if ( IS_ERR(info) )
> > +return PTR_ERR(info);
> > +
> > +feat_type = psr_cbm_type_to_feat_type(type);
> > +if ( !test_bit(feat_type, >feat_mask) )
> > +return -ENOENT;
> > +
> > +/*
> > + * Step 0:
> > + * old_cos means the COS ID current domain is using. By default, it is 
> > 0.
> > + *
> > + * For every COS ID, there is a reference count to record how many 
> > domains
> > + * are using the COS register corresponding to this COS ID.
> > + * - If ref[old_cos] is 0, that means this COS is not used by any 
> > domain.
> > + * - If ref[old_cos] is 1, that means this COS is only used by current
> > + *   domain.
> > + * - If ref[old_cos] is more than 1, that mean multiple domains are 
> > using
> > + *   this COS.
> > + */
> > +old_cos = d->arch.psr_cos_ids[socket];
> > +if ( old_cos > MAX_COS_REG_CNT )
> > +return -EOVERFLOW;
> 
> Doesn't this need to be >= ? And isn't this happening an indication
> of a bug, i.e. shouldn't there be an ASSERT_UNREACHABLE() ahead
> of the return?
> 
Sorry. This has been corrected in next version. Thanks!

> > +ref = info->cos_ref;
> > +
> > +/*
> > + * Step 1:
> > + * Assemle a value array to store all featues cos_reg_val[old_cos].
> 
> Assemble ... features ...
> 
Oh, sorry.

[...]
> > +/*
> > + * Step 2:
> > + * Try to find if there is already a COS ID on which all features' 
> > values
> > + * are same as the array. Then, we can reuse this COS ID.
> > + */
> > +cos = find_cos(val_array, array_len, feat_type, info);
> > +if ( cos >= 0 )
> > +{
> > +if ( cos == old_cos )
> > +{
> > +spin_unlock(>ref_lock);
> > +xfree(val_array);
> > +return 0;
> > +}
> 
> You could save a level of indentation if you inverted the outer if()'s
> condition and made the code above "else if".
> 
Will consider it.

> > +}
> > +else
> > +{
> > +/*
> > + * Step 3:
> > + * If fail to find, we need allocate a new COS ID.
> > + * 

Re: [Xen-devel] [PATCH v8 07/24] x86: refactor psr: implement get value flow.

[Yi Sun]

On 17-03-08 08:35:53, Jan Beulich wrote:
> >>> On 15.02.17 at 09:49,  wrote:
> > @@ -260,9 +263,22 @@ static bool l3_cat_get_feat_info(const struct 
> > feat_node *feat,
> >  return true;
> >  }
> >  
> > +static bool l3_cat_get_val(const struct feat_node *feat, unsigned int cos,
> > +   enum cbm_type type, uint64_t *val)
> > +{
> > +if ( cos > feat->info.l3_cat_info.cos_max )
> > +/* Use default value. */
> > +cos = 0;
> > +
> > +*val = feat->cos_reg_val[cos];
> > +
> > +return true;
> 
> This one never failing I wonder whether the same will apply to the
> later ones. If so, there's little point in returning a boolean here, but
> instead you could return the value instead of using indirection.
> 
I have modified this function to 'void' in next version.

> >  static void __init parse_psr_bool(char *s, char *value, char *feature,
> > @@ -482,12 +498,14 @@ static struct psr_socket_info 
> > *get_socket_info(unsigned int socket)
> >  return socket_info + socket;
> >  }
> >  
> > -int psr_get_info(unsigned int socket, enum cbm_type type,
> > - uint32_t data[], unsigned int array_len)
> > +static int psr_get(unsigned int socket, enum cbm_type type,
> 
> The immediately preceding patch introduced thus function, and
> now you're changing its name. Please give it the intended final
> name right away.
> 
The name is not changed. You can see below lines. Here is just to implement
a helper function which is called by 'psr_get_info'.

> > +   uint32_t data[], unsigned int array_len,
> > +   struct domain *d, uint64_t *val)
> 
> const struct domain *, but I'm not even sure that's an appropriate
> parameter here:
> 
> > @@ -498,6 +516,15 @@ int psr_get_info(unsigned int socket, enum cbm_type 
> > type,
> >  if ( feat->feature != feat_type )
> >  continue;
> >  
> > +if ( d )
> > +{
> > +cos = d->arch.psr_cos_ids[socket];
> 
> You could equally well pass a more constrained pointer, like
> psr_cos_ids[] on its own. But of course much depends on whether
> you'll need d for other things in this function in later patches.
> 
Ok, thanks! Will consider the parameter.

> > +if ( feat->ops.get_val(feat, cos, type, val) )
> > +return 0;
> > +else
> > +break;
> > +}
> > +
> >  if ( feat->ops.get_feat_info(feat, data, array_len) )
> >  return 0;
> >  else
> 
> Looking at the context here - is it really a good idea to overload the
> function in this way, rather than creating a second one? Your
> only complicating the live of the callers, as can be seen e.g. ...
> 
These codes were separated into two functions before, 'psr_get_info' and
'psr_get_val'. But there are some common codes. So, Konrad suggested me
to create a helper function to reduce redundant codes.

> > @@ -507,10 +534,16 @@ int psr_get_info(unsigned int socket, enum cbm_type 
> > type,
> >  return -ENOENT;
> >  }
> >  
> > -int psr_get_l3_cbm(struct domain *d, unsigned int socket,
> > -   uint64_t *cbm, enum cbm_type type)
> > +int psr_get_info(unsigned int socket, enum cbm_type type,
> > + uint32_t data[], unsigned int array_len)
> > +{
> > +return psr_get(socket, type, data, array_len, NULL, NULL);
> 
> ... here and ...
> 
> > +}
> > +
> > +int psr_get_val(struct domain *d, unsigned int socket,
> > +uint64_t *val, enum cbm_type type)
> >  {
> > -return 0;
> > +return psr_get(socket, type, NULL, 0, d, val);
> >  }
> 
> ... here (it is a bad sign that both pass NULL on either side).
> 
Yes, these things look not good. But to keep a common helper I have to pass
all necessary parameters into it. What is your suggestion?

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

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

Re: [Xen-devel] [PATCH v8 06/24] x86: refactor psr: implement get hw info flow.

[Yi Sun]

On 17-03-08 08:15:33, Jan Beulich wrote:
> >>> On 15.02.17 at 09:49,  wrote:
> > --- a/xen/arch/x86/psr.c
> > +++ b/xen/arch/x86/psr.c
> > @@ -84,6 +84,7 @@ enum psr_feat_type {
> >  PSR_SOCKET_L3_CAT = 0,
> >  PSR_SOCKET_L3_CDP,
> >  PSR_SOCKET_L2_CAT,
> > +PSR_SOCKET_UNKNOWN = 0x,
> 
> Any reason to use this value, instead of just the next sequential one?
> 
This is an error value used below, in 'psr_cbm_type_to_feat_type'. To make it
explicitly different, I assign a big value to it.

> > @@ -182,6 +186,24 @@ static void free_feature(struct psr_socket_info *info)
> >  }
> >  }
> >  
> > +static enum psr_feat_type psr_cbm_type_to_feat_type(enum cbm_type type)
> > +{
> > +enum psr_feat_type feat_type;
> > +
> > +/* Judge if feature is enabled. */
> > +switch ( type )
> > +{
> > +case PSR_CBM_TYPE_L3:
> > +feat_type = PSR_SOCKET_L3_CAT;
> > +break;
> > +default:
> > +feat_type = PSR_SOCKET_UNKNOWN;
> > +break;
> > +}
> > +
> > +return feat_type;
> > +}
> 
> The comment ahead of the switch() doesn't seem to describe what's
> being done - there certainly is no check here whether anything is
> enabled or disabled.
> 
Sorry for that, will remove the comment.

> > @@ -225,8 +247,22 @@ static unsigned int l3_cat_get_cos_max(const struct 
> > feat_node *feat)
> >  return feat->info.l3_cat_info.cos_max;
> >  }
> >  
> > +static bool l3_cat_get_feat_info(const struct feat_node *feat,
> > + uint32_t data[], unsigned int array_len)
> > +{
> > +if ( !data || 3 > array_len )
> 
> I think the 3 here was picked upon already: This check does not
> guarantee there's no array overrun ...
> 
Yes, Roger has suggested to change it to 'array_len != PSR_INFO_SIZE'.

> > +return false;
> > +
> > +data[CBM_LEN] = feat->info.l3_cat_info.cbm_len;
> > +data[COS_MAX] = feat->info.l3_cat_info.cos_max;
> > +data[PSR_FLAG] = 0;
> 
> ... anywhere here. For that you'd need a *_MAX- or *_NUM-type
> constant (defined next to the array index constants).
> 
This is defined in next version.

[...]
> > --- a/xen/include/asm-x86/psr.h
> > +++ b/xen/include/asm-x86/psr.h
> > @@ -19,19 +19,24 @@
> >  #include 
> >  
> >  /* CAT cpuid level */
> > -#define PSR_CPUID_LEVEL_CAT   0x10
> > +#define PSR_CPUID_LEVEL_CAT0x10
> >  
> >  /* Resource Type Enumeration */
> > -#define PSR_RESOURCE_TYPE_L30x2
> > +#define PSR_RESOURCE_TYPE_L3   0x2
> >  
> >  /* L3 Monitoring Features */
> > -#define PSR_CMT_L3_OCCUPANCY   0x1
> > +#define PSR_CMT_L3_OCCUPANCY   0x1
> >  
> >  /* CDP Capability */
> > -#define PSR_CAT_CDP_CAPABILITY   (1u << 2)
> > +#define PSR_CAT_CDP_CAPABILITY (1u << 2)
> >  
> >  /* L3 CDP Enable bit*/
> > -#define PSR_L3_QOS_CDP_ENABLE_BIT   0x0
> > +#define PSR_L3_QOS_CDP_ENABLE_BIT  0x0
> 
> Are all these adjustments really needed here?
> 
Per Wei's suggestion to make codes neat.

> > +/* Used by psr_get_info() */
> > +#define CBM_LEN0
> > +#define COS_MAX1
> > +#define PSR_FLAG   2
> 
> Neither comment nor names are helpful to understand the purpose of
> these constants. How about PSR_INFO_IDX_* or some such?
> 
Ok will do it in next version.

> Jan

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

Re: [Xen-devel] [PATCH v8 04/24] x86: refactor psr: implement CPU init and free flow.

[Yi Sun]

On 17-03-08 07:56:54, Jan Beulich wrote:
> >>> On 15.02.17 at 09:49,  wrote:

[...]
> > -static int psr_cpu_prepare(unsigned int cpu)
> > +static void cpu_init_work(void)
> > +{
> > +struct psr_socket_info *info;
> > +unsigned int socket;
> > +unsigned int cpu = smp_processor_id();
> > +struct feat_node *feat;
> > +struct cpuid_leaf regs = { .a = 0, .b = 0, .c = 0, .d = 0 };
> 
> I don't see you needing an initializer here at all, but if you really
> want one for some reason, the same effect can be had with just
> {}.
> 
Konrad suggested me to initialize it like this in v5 patch review comments.
I think he has experienced some strange issues when he forgot to set _all_
the entries a structure allocated on the stack.

> > +if ( !cpu_has(_cpu_data, X86_FEATURE_PQE) )
> 
> Do you really mean to not universally check the global (boot CPU)
> flag? I.e. possibly differing behavior on different CPUs?
> 
Yes, different sockets may have different configurations. E.g. sockt 0 has
PQE support but socket 1 does not. Per my info, there is only one boot cpu
no matter how many sockets there are.

> > +return;
> > +else if ( current_cpu_data.cpuid_level < PSR_CPUID_LEVEL_CAT )
> 
> Pointless "else".
> 
Thanks, will remove it.

> > +{
> > +__clear_bit(X86_FEATURE_PQE, current_cpu_data.x86_capability);
> 
> setup_clear_cpu_cap() if you use boot_cpu_has() above.
> 
> > +return;
> > +}
> > +
> > +socket = cpu_to_socket(cpu);
> > +info = socket_info + socket;
> > +if ( info->feat_mask )
> > +return;
> > +
> > +INIT_LIST_HEAD(>feat_list);
> > +spin_lock_init(>ref_lock);
> > +
> > +cpuid_count_leaf(PSR_CPUID_LEVEL_CAT, 0, );
> > +if ( regs.b & PSR_RESOURCE_TYPE_L3 )
> > +{
> > +cpuid_count_leaf(PSR_CPUID_LEVEL_CAT, 1, );
> > +
> > +feat = feat_l3_cat;
> > +/* psr_cpu_prepare will allocate it on subsequent CPU onlining. */
> > +feat_l3_cat = NULL;
> 
> I don't think the comment is very useful: You've consumed the object,
> so you simply should not leave a dangling pointer (or else you'd risk
> multiple use).
> 
Will remove it.

> >  static void psr_cpu_init(void)
> >  {
> > +if ( socket_info )
> > +cpu_init_work();
> > +
> >  psr_assoc_init();
> >  }
> >  
> >  static void psr_cpu_fini(unsigned int cpu)
> >  {
> > +if ( socket_info )
> > +cpu_fini_work(cpu);
> >  return;
> >  }
> 
> Is it really useful to use another layer of helper functions here?
> 
The reason we define 'cpu_fini_work' is to match 'cpu_init_work'. If we move
codes of 'cpu_init_work' into 'psr_cpu_init', the codes look messy. That is
the reason we define 'cpu_init_work'. Do you think if it is acceptable to you?

> Jan

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

Re: [Xen-devel] Xen 4.8.0 dom0pvh=1 causes ext4 filesystem corruption

[Boris Ostrovsky]

On 03/09/2017 07:19 PM, Andrew Cooper wrote:

On 10/03/2017 00:09, Steven Haigh wrote:

On 10/03/17 02:13, Valtteri Kiviniemi wrote:

Hi,

Yesterday I decided to upgrade my Xen version from 4.6.0 to 4.8.0. I
compiled it from source and at the same time I compiled the latest Linux
kernel (4.10.1).

When rebooting I decided to try if dom0 PVH would work (with previous
Xen version it just caused kernel panic). Seemed to boot fine until
systemd started mounting the root filesystem and then the console was
filled with ext4 errors. Couldn't even log in.

Booting with a systemrescuecd and running fsck just caused the whole
filesystem to be re-attached in thousands of small pieces under
lost+found. I was sure that this was a some kind of hardware failure, so
I switched my hard drives and did a clean reinstall for dom0 and tried
again. Again, after a reboot the whole rootfs was completely corrupted.

Second reinstall and this time I disabled dom0 PVH and the system booted
just fine, and no ext4 errors. My root filesystem is just a simple Linux
software raid1 with ext4 on top of it.

Now that I started thinking I have also had strange ext4 errors
happening inside my guests, so I also disabled PVH from all the guests.
With guests the ext4 error is always the same: "EXT4-fs error (device
xvda1): ext4_iget:4665: inode #317: comm find: bogus i_mode (135206)"

Unfortunately I don't have any logs from the dom0 corruption as I can't
even log in to the system when dom0 PVH is enabled. The corruption
happens instantly during system bootup.

I have this happen a lot using pvh mode in previous Xen versions. Is it
supposed to be 'working' yet or is it still not recommended for use?


That version of PVH has just been ripped out of Linux, and is in the
process of being ripped out of the hypervisor.

The replacement, accessed by using dom0=pvh is available in master, will
be present in Xen 4.9, and should work with Linux 4.11 and FreeBSD
Current.  (Roger, Boris - please correct me if I am wrong.)



There is nothing in Linux currently to support PVH dom0, only domU. I 
haven't tried booting dom0 in PVH mode yet but I doubt anything good 
will come out of this.


This is something I will be working on next.

-boris




The same Linux and FreeBSD versions should function perfectly well as
plain domUs in PVH mode, by selecting device_model=none in the domain
configuration.  (Dom0 is rather more complicated than domU, due to the
shared responsibility of real hardware with Xen.)

~Andrew



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

Re: [Xen-devel] [early RFC] ARM PCI Passthrough design document

[Konrad Rzeszutek Wilk]

On Thu, Mar 09, 2017 at 01:26:45PM +, Julien Grall wrote:
> Hi Konrad,
> 
> On 09/03/17 11:17, Konrad Rzeszutek Wilk wrote:
> > On Thu, Mar 09, 2017 at 11:59:51AM +0900, Roger Pau Monné wrote:
> > > On Wed, Mar 08, 2017 at 02:12:09PM -0500, Konrad Rzeszutek Wilk wrote:
> > > > On Wed, Mar 08, 2017 at 07:06:23PM +, Julien Grall wrote:
> > > > > Hi,
> > > > > 
> > > > > On 02/02/17 23:06, Stefano Stabellini wrote:
> > > > > > On Thu, 2 Feb 2017, Julien Grall wrote:
> > > > > > > On 01/02/17 10:55, Roger Pau Monné wrote:
> > > > > > > > On Wed, Jan 25, 2017 at 06:53:20PM +, Julien Grall wrote:
> > > > > > > > > On 24/01/17 20:07, Stefano Stabellini wrote:
> > > > > > > > > > On Tue, 24 Jan 2017, Julien Grall wrote:
> > > > > > > For DT, I would have a fallback on mapping the root complex to 
> > > > > > > DOM0 if we
> > > > > > > don't support it. So DOM0 could still use PCI.
> > > > > > > 
> > > > > > > For ACPI, I am expecting all the platform ECAM compliant or 
> > > > > > > require few
> > > > > > > quirks. So I would mandate the support of the root complex in Xen 
> > > > > > > in order to
> > > > > > > get PCI supported.
> > > > > > 
> > > > > > Sound good. Ack.
> > > > > 
> > > > > I am currently rewriting the design document to take into account all 
> > > > > the
> > > > > comments and follow the path to have the host bridge in Xen and DOM0 
> > > > > will
> > > > > get an emulated one.
> > > > > 
> > > > > I began to look at scanning and configuring PCI devices in Xen. 
> > > > > Looking at
> > > > > the PCI firmware specification, the firmware is not required to 
> > > > > configure
> > > > > the BAR register other than for boot and console devices. This means 
> > > > > an
> > > > > Operating System (or the hypervisor in our case) may have to 
> > > > > configure some
> > > > > devices.
> > > > > 
> > > > > In order to configure the BAR register, Xen would need to know where 
> > > > > are the
> > > > > PCI resources. On ACPI they can be found in ASL, however Xen is not 
> > > > > able to
> > > > > parse it. In the case of Device Tree with can retrieve the PCI 
> > > > > resources
> > > > > using the property "ranges".
> > > > > 
> > > > > I can see a couple of solutions:
> > > > >   1# Rely on DOM0 to do the PCI configuration. This means that 
> > > > > DOM0 should
> > > > > see all the PCI devices and therefore will not be possible to hide 
> > > > > from DOM0
> > > > > if we know at boot a device will be used by a guest (i.e something 
> > > > > similar
> > > > > to pciback.hide but directly handled in Xen).
> > > > 
> > > > .. this as for SR-IOV devices you need the drivers to kick the hardware
> > > > to generate the new bus addresses. And those (along with the BAR 
> > > > regions) are
> > > > not visible in ACPI (they are constructued dynamically).
> > > 
> > > There's already code in Xen [0] to find out the size of the BARs of SR-IOV
> > > devices, but I'm not sure what's the intended usage of that, does it need 
> > > to
> > > happen _after_ the driver in Dom0 has done whatever magic for this to 
> > > work?
> > 
> > Yes. This is called via the PHYSDEVOP_pci_device_add hypercall when
> > the device driver in dom0 has finished "creating" the VF. See 
> > drivers/xen/pci.c
> 
> We are thinking to not use PHYSDEVOP_pci_device_add hypercall for ARM and do
> the PCI scanning in Xen.
> 
> If I understand correctly what you said, only the PCI driver will be able to
> kick SR-IOV device and Xen would not be able to detect the device until it
> has been fully configured. So it would mean that we have to keep
> PHYSDEVOP_pci_device_add around to know when Xen can use the device.
> 
> Am I correct?

Yes. Unless the PCI drivers come up with some other way to tell the
OS that oh, hey, there is this new PCI device with this BDF.

Or the underlaying bus on ARM can send some 'new device' information?

> 
> Cheers,
> 
> -- 
> Julien Grall

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

Re: [Xen-devel] Xen 4.8.0 dom0pvh=1 causes ext4 filesystem corruption

[Andrew Cooper]

On 10/03/2017 00:09, Steven Haigh wrote:
> On 10/03/17 02:13, Valtteri Kiviniemi wrote:
>> Hi,
>>
>> Yesterday I decided to upgrade my Xen version from 4.6.0 to 4.8.0. I
>> compiled it from source and at the same time I compiled the latest Linux
>> kernel (4.10.1).
>>
>> When rebooting I decided to try if dom0 PVH would work (with previous
>> Xen version it just caused kernel panic). Seemed to boot fine until
>> systemd started mounting the root filesystem and then the console was
>> filled with ext4 errors. Couldn't even log in.
>>
>> Booting with a systemrescuecd and running fsck just caused the whole
>> filesystem to be re-attached in thousands of small pieces under
>> lost+found. I was sure that this was a some kind of hardware failure, so
>> I switched my hard drives and did a clean reinstall for dom0 and tried
>> again. Again, after a reboot the whole rootfs was completely corrupted.
>>
>> Second reinstall and this time I disabled dom0 PVH and the system booted
>> just fine, and no ext4 errors. My root filesystem is just a simple Linux
>> software raid1 with ext4 on top of it.
>>
>> Now that I started thinking I have also had strange ext4 errors
>> happening inside my guests, so I also disabled PVH from all the guests.
>> With guests the ext4 error is always the same: "EXT4-fs error (device
>> xvda1): ext4_iget:4665: inode #317: comm find: bogus i_mode (135206)"
>>
>> Unfortunately I don't have any logs from the dom0 corruption as I can't
>> even log in to the system when dom0 PVH is enabled. The corruption
>> happens instantly during system bootup.
> I have this happen a lot using pvh mode in previous Xen versions. Is it
> supposed to be 'working' yet or is it still not recommended for use?

That version of PVH has just been ripped out of Linux, and is in the
process of being ripped out of the hypervisor.

The replacement, accessed by using dom0=pvh is available in master, will
be present in Xen 4.9, and should work with Linux 4.11 and FreeBSD
Current.  (Roger, Boris - please correct me if I am wrong.)

The same Linux and FreeBSD versions should function perfectly well as
plain domUs in PVH mode, by selecting device_model=none in the domain
configuration.  (Dom0 is rather more complicated than domU, due to the
shared responsibility of real hardware with Xen.)

~Andrew

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

Re: [Xen-devel] Xen 4.8.0 dom0pvh=1 causes ext4 filesystem corruption

[Steven Haigh]

On 10/03/17 02:13, Valtteri Kiviniemi wrote:
> Hi,
> 
> Yesterday I decided to upgrade my Xen version from 4.6.0 to 4.8.0. I
> compiled it from source and at the same time I compiled the latest Linux
> kernel (4.10.1).
> 
> When rebooting I decided to try if dom0 PVH would work (with previous
> Xen version it just caused kernel panic). Seemed to boot fine until
> systemd started mounting the root filesystem and then the console was
> filled with ext4 errors. Couldn't even log in.
> 
> Booting with a systemrescuecd and running fsck just caused the whole
> filesystem to be re-attached in thousands of small pieces under
> lost+found. I was sure that this was a some kind of hardware failure, so
> I switched my hard drives and did a clean reinstall for dom0 and tried
> again. Again, after a reboot the whole rootfs was completely corrupted.
> 
> Second reinstall and this time I disabled dom0 PVH and the system booted
> just fine, and no ext4 errors. My root filesystem is just a simple Linux
> software raid1 with ext4 on top of it.
> 
> Now that I started thinking I have also had strange ext4 errors
> happening inside my guests, so I also disabled PVH from all the guests.
> With guests the ext4 error is always the same: "EXT4-fs error (device
> xvda1): ext4_iget:4665: inode #317: comm find: bogus i_mode (135206)"
> 
> Unfortunately I don't have any logs from the dom0 corruption as I can't
> even log in to the system when dom0 PVH is enabled. The corruption
> happens instantly during system bootup.

I have this happen a lot using pvh mode in previous Xen versions. Is it
supposed to be 'working' yet or is it still not recommended for use?

-- 
Steven Haigh

Email: net...@crc.id.au
Web: https://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897



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

Re: [Xen-devel] [PATCH net v3] xen-netback: fix race condition on XenBus disconnect

[kbuild test robot]

Hi Igor,

[auto build test WARNING on net/master]

url:
https://github.com/0day-ci/linux/commits/Igor-Druzhinin/xen-netback-fix-race-condition-on-XenBus-disconnect/20170310-055447
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

   include/linux/compiler.h:264:8: sparse: attribute 'no_sanitize_address': 
unknown attribute
>> drivers/net/xen-netback/interface.c:178:22: sparse: incompatible types in 
>> comparison expression (different address spaces)
   drivers/net/xen-netback/interface.c:237:22: sparse: incompatible types in 
comparison expression (different address spaces)
   drivers/net/xen-netback/interface.c:389:22: sparse: incompatible types in 
comparison expression (different address spaces)

vim +178 drivers/net/xen-netback/interface.c

   162  }
   163  
   164  static int xenvif_start_xmit(struct sk_buff *skb, struct net_device 
*dev)
   165  {
   166  struct xenvif *vif = netdev_priv(dev);
   167  struct xenvif_queue *queue = NULL;
   168  unsigned int num_queues;
   169  u16 index;
   170  struct xenvif_rx_cb *cb;
   171  
   172  BUG_ON(skb->dev != dev);
   173  
   174  /* Drop the packet if queues are not set up.
   175   * This handler should be called inside an RCU read section
   176   * so we don't need to enter it here explicitly.
   177   */
 > 178  num_queues = rcu_dereference(vif)->num_queues;
   179  if (num_queues < 1)
   180  goto drop;
   181  
   182  /* Obtain the queue to be used to transmit this packet */
   183  index = skb_get_queue_mapping(skb);
   184  if (index >= num_queues) {
   185  pr_warn_ratelimited("Invalid queue %hu for packet on 
interface %s\n.",
   186  index, vif->dev->name);

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation

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

Re: [Xen-devel] [PATCH v5 2/3] x86: Remap GDT tables in the Fixmap section

[Boris Ostrovsky]

On 03/09/2017 05:31 PM, Thomas Garnier wrote:
> On Thu, Mar 9, 2017 at 2:13 PM, Boris Ostrovsky
>  wrote:
 I don't have any experience with Xen so it would be great if virtme can 
 test it.
>>> I am pretty sure I tested this series at some point but I'll test it again.
>>>
>>
>> Fails 32-bit build:
>>
>>
>> /home/build/linux-boris/arch/x86/kvm/vmx.c: In function ‘segment_base’:
>> /home/build/linux-boris/arch/x86/kvm/vmx.c:2054: error: ‘host_gdt’
>> undeclared (first use in this function)
>> /home/build/linux-boris/arch/x86/kvm/vmx.c:2054: error: (Each undeclared
>> identifier is reported only once
>> /home/build/linux-boris/arch/x86/kvm/vmx.c:2054: error: for each
>> function it appears in.)
>> /home/build/linux-boris/arch/x86/kvm/vmx.c:2054: error: type defaults to
>> ‘int’ in declaration of ‘type name’
>> /home/build/linux-boris/arch/x86/kvm/vmx.c:2054: error: type defaults to
>> ‘int’ in declaration of ‘type name’
>> /home/build/linux-boris/arch/x86/kvm/vmx.c:2054: warning: initialization
>> from incompatible pointer type
>> /home/build/linux-boris/arch/x86/kvm/vmx.c:2054: warning: unused
>> variable ‘gdt’
>>
>>
>> -boris
> It seems that I forgot to remove line 2054 on the rebase. My 32-bit
> build comes clean but I assume it is not good enough compare to the
> full version I build for 64-bit KVM testing.
>
> Remove just this line and it should build fine, I will fix this on the
> next iteration.
>
> Thanks for testing,
>


So this, in fact, does break Xen in that the hypercall to set GDT fails.

I will have lo look at this tomorrow but I definitely at least built
with v3 of this series. And I don't see why I wouldn't have tested it
once I built it.

-boris

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-xsm5 xen-buildfail REGR. vs. 106534
 build-amd64-oldkern   5 kernel-build fail REGR. vs. 106534

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 106534
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 106534
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 106534
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 106534
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 106534
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 106534
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 106534
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 106534

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 build-arm64   5 xen-buildfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 build-arm64-xsm   5 xen-buildfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 build-arm64-pvops 5 kernel-build fail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   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-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 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

version targeted for testing:
 xen  bd8451964078b006081fcef6d169961a3a6f746a
baseline version:
 xen  4036e7c592905c2292cdeba8269e969959427237

Last test of basis   106534  2017-03-07 19:14:51 Z2 days
Failing since106547  2017-03-08 08:59:30 Z1 days3 attempts
Testing 

Re: [Xen-devel] [PATCH v5 2/3] x86: Remap GDT tables in the Fixmap section

[Thomas Garnier]

On Thu, Mar 9, 2017 at 2:13 PM, Boris Ostrovsky
 wrote:
>
>>> I don't have any experience with Xen so it would be great if virtme can 
>>> test it.
>>
>> I am pretty sure I tested this series at some point but I'll test it again.
>>
>
>
> Fails 32-bit build:
>
>
> /home/build/linux-boris/arch/x86/kvm/vmx.c: In function ‘segment_base’:
> /home/build/linux-boris/arch/x86/kvm/vmx.c:2054: error: ‘host_gdt’
> undeclared (first use in this function)
> /home/build/linux-boris/arch/x86/kvm/vmx.c:2054: error: (Each undeclared
> identifier is reported only once
> /home/build/linux-boris/arch/x86/kvm/vmx.c:2054: error: for each
> function it appears in.)
> /home/build/linux-boris/arch/x86/kvm/vmx.c:2054: error: type defaults to
> ‘int’ in declaration of ‘type name’
> /home/build/linux-boris/arch/x86/kvm/vmx.c:2054: error: type defaults to
> ‘int’ in declaration of ‘type name’
> /home/build/linux-boris/arch/x86/kvm/vmx.c:2054: warning: initialization
> from incompatible pointer type
> /home/build/linux-boris/arch/x86/kvm/vmx.c:2054: warning: unused
> variable ‘gdt’
>
>
> -boris

It seems that I forgot to remove line 2054 on the rebase. My 32-bit
build comes clean but I assume it is not good enough compare to the
full version I build for 64-bit KVM testing.

Remove just this line and it should build fine, I will fix this on the
next iteration.

Thanks for testing,

-- 
Thomas

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

Re: [Xen-devel] [PATCH v16 4/9] x86: add multiboot2 protocol support for EFI platforms

[Konrad Rzeszutek Wilk]

> > All worked fine.
> 
> 
> 
> > 
> > konrad-Super-Server login: [  188.181526] reboot: Restarting system
> > (XEN) Hardware Dom0 shutdown: rebooting machine
> > (XEN) APIC error on CPU0: 40(00)
> > 
> > ... reboot.
> 
> So as I've mentioned you have to run 'xl info' and look at nr_cpus to
> see the issue.

Odd, I must have missed it. Either way see the inline serial capture.
With both 'xl info' reporting expected values.
> 
> 
> 
> >  Starting Notify bootloader 
> > tha[^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G  OK  ] Started 
> > Notify bootloader that boot was successful.
> > 
> > Ubuntu 16.10 konrad-Super-Server hvc0
> > 
> > konrad-Super-Server login: 
> > 
> 
> Still missing 'xl info'.
> 
fs0:\> cd efi

fs0:\EFI> cd xen

fs0:\EFI\xen> xen
 Xen 4.9-unstable
(XEN) Xen version 4.9-unstable (konrad@) (gcc (Ubuntu 6.2.0-5ubuntu12) 6.2.0 
20161005) debug=y  Tue Mar  7 22:13:08 EST 2017
(XEN) Latest ChangeSet: Tue Feb 21 20:19:58 2017 +0100 git:e4ccbd0
(XEN) Bootloader: EFI
(XEN) Command line: console=vga,com1 com1=115200,8n1 iommu=verbose ucode=scan 
flask=disabled conring_size=2097152  loglvl=all
(XEN) Xen image load base address: 0x2980
(XEN) Video information:
(XEN)  VGA is graphics mode 1280x1024, 32 bpp
(XEN) Disc information:
(XEN)  Found 0 MBR signatures
(XEN)  Found 1 EDD information structures
(XEN) EFI RAM map:
(XEN)   - 00058000 (usable)
(XEN)  00058000 - 00059000 (reserved)
(XEN)  00059000 - 0009f000 (usable)
(XEN)  0009f000 - 000a (reserved)
(XEN)  0010 - 2ae33000 (usable)
(XEN)  2ae33000 - 2ae34000 (ACPI NVS)
(XEN)  2ae34000 - 2ae7e000 (reserved)
(XEN)  2ae7e000 - 2e8c1000 (usable)
(XEN)  2e8c1000 - 2ec64000 (reserved)
(XEN)  2ec64000 - 2eddf000 (usable)
(XEN)  2eddf000 - 2f3eb000 (ACPI NVS)
(XEN)  2f3eb000 - 2000 (reserved)
(XEN)  2000 - 3000 (usable)
(XEN)  3000 - 3800 (reserved)
(XEN)  e000 - f000 (reserved)
(XEN)  fe00 - fe011000 (reserved)
(XEN)  fec0 - fec01000 (reserved)
(XEN)  fee0 - fee01000 (reserved)
(XEN)  ff00 - 0001 (reserved)
(XEN)  0001 - 0008c340 (usable)
(XEN) ACPI: RSDP 2EE67000, 0024 (r2 SUPERM)
(XEN) ACPI: XSDT 2EE670B0, 00DC (r1 SUPERM   SUPERM  1072009 AMI 10013)
(XEN) -MB  1072009 INTL 20120913)
(XEN) ACPI: FACS 2F3E9F80, 0040
(XEN) ACPI: APIC 2EE8A6B8, 00BC (r3  1072009 AMI 10013)
(XEN) ACPI: FPDT 2EE8A778, 0044 (r1  1072009 AMI 10013)
(XEN) ACPI: FIDT 2EE8A7C0, 009C (r1  1072009 AMI 10013)
(XEN) ACPI: MCFG 2EE8A860, 003C (r1 SUPERM SMCI--MB  1072009 MSFT   97)
(XEN) ACPI: HPET 2EE8A8A0, 0038 (r1 SUPERM SMCI--MB  1072009 AMI.5000B)
(XEN) ACPI: LPIT 2EE8A8D8, 0094 (r1 INTEL   SKL0 MSFT   5F)
(XEN) ACPI: SSDT 2EE8A970, 0248 (r2 INTEL  sensrhub0 INTL 20120913)
(XEN) ACPI: SSDT 2EE8ABB8, 2BAE (r2 INTEL  PtidDevc 1000 INTL 20120913)
(XEN) ACPI: SSDT 2EE8D768, 0BE3 (r2 INTEL  Ther_Rvp 1000 INTL 20120913)
(XEN) ACPI: DBGP 2EE8E350, 0034 (r1 INTEL  0 MSFT   5F)
(XEN) ACPI: DBG2 2EE8E388, 0054 (r0 INTEL  0 MSFT   5F)
(XEN) ACPI: SSDT 2EE8E3E0, 06FD (r2  INTEL xh_rvp080 INTL 20120913)
(XEN) ACPI: SSDT 2EE8EAE0, 546C (r2 SaSsdt  SaSsdt  3000 INTL 20120913)
(XEN) ACPI: UEFI 2EE93F50, 0042 (r10 0)
(XEN) ACPI: SSDT 2EE93F98, 0E73 (r2 CpuRef  CpuSsdt 3000 INTL 20120913)
(XEN) ACPI: DMAR 2EE94E10, 00A8 (r1 INTEL  SKL 1 INTL1)
(XEN) ACPI: ASF! 2EE94EB8, 00A5 (r32 INTEL   HCG1 TFSMF4240)
(XEN) ACPI: EINJ 2EE94F60, 0130 (r1AMI AMI.EINJ0 AMI.0)
(XEN) ACPI: ERST 2EE95090, 0230 (r1  AMIER AMI.ERST0 AMI.0)
(XEN) ACPI: BERT 2EE952C0, 0030 (r1AMI AMI.BERT0 AMI.0)
(XEN) ACPI: HEST 2EE952F0, 027C (r1AMI AMI.HEST0 AMI.0)
(XEN) ACPI: BGRT 2EE95570, 0038 (r1 SUPERM SMCI--MB  1072009 AMI 10013)
(XEN) System RAM: 32541MB (33322560kB)
(XEN) No NUMA configuration found
(XEN) Faking a node at -0008c340
(XEN) Domain heap initialised
(XEN) Allocated console ring of 1048576 KiB.
(XEN) vesafb: framebuffer at 0x9000, mapped to 0x82c000201000, using 
5120k, total 5120k
(XEN) vesafb: mode is 1280x1024driver default
(XEN) ACPI: PM-Timer IO Port: 0x1808 (32 bits)
(XEN) ACPI: v5 SLEEP INFO: control[0:0], status[0:0]
(XEN) ACPI: SLEEP INFO: pm1x_cnt[1:1804,1:0], pm1x_evt[1:1800,1:0]
(XEN) ACPI: 32/64X FACS address mismatch in FADT - 2f3e9f80/, 

Re: [Xen-devel] [PATCH v5 2/3] x86: Remap GDT tables in the Fixmap section

[Boris Ostrovsky]

>> I don't have any experience with Xen so it would be great if virtme can test 
>> it.
>
> I am pretty sure I tested this series at some point but I'll test it again.
>


Fails 32-bit build:


/home/build/linux-boris/arch/x86/kvm/vmx.c: In function ‘segment_base’:
/home/build/linux-boris/arch/x86/kvm/vmx.c:2054: error: ‘host_gdt’
undeclared (first use in this function)
/home/build/linux-boris/arch/x86/kvm/vmx.c:2054: error: (Each undeclared
identifier is reported only once
/home/build/linux-boris/arch/x86/kvm/vmx.c:2054: error: for each
function it appears in.)
/home/build/linux-boris/arch/x86/kvm/vmx.c:2054: error: type defaults to
‘int’ in declaration of ‘type name’
/home/build/linux-boris/arch/x86/kvm/vmx.c:2054: error: type defaults to
‘int’ in declaration of ‘type name’
/home/build/linux-boris/arch/x86/kvm/vmx.c:2054: warning: initialization
from incompatible pointer type
/home/build/linux-boris/arch/x86/kvm/vmx.c:2054: warning: unused
variable ‘gdt’


-boris

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

Re: [Xen-devel] [PATCH v5 2/3] x86: Remap GDT tables in the Fixmap section

[Boris Ostrovsky]

On 03/09/2017 04:54 PM, Thomas Garnier wrote:
> On Thu, Mar 9, 2017 at 1:46 PM, Andy Lutomirski  wrote:
>> On Thu, Mar 9, 2017 at 1:43 PM, Andrew Cooper  
>> wrote:
>>> On 09/03/2017 21:32, Andy Lutomirski wrote:
 On Mon, Mar 6, 2017 at 2:03 PM, Thomas Garnier  wrote:

> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -710,7 +710,7 @@ static void load_TLS_descriptor(struct thread_struct 
> *t,
>
> *shadow = t->tls_array[i];
>
> -   gdt = get_cpu_gdt_table(cpu);
> +   gdt = get_cpu_gdt_rw(cpu);
> maddr = arbitrary_virt_to_machine([GDT_ENTRY_TLS_MIN+i]);
> mc = __xen_mc_entry(0);
 Boris, is this right?  I don't see why it wouldn't be, but Xen is special.
>>> Under Xen PV, the GDT is already read-only at this point.  (It is not
>>> safe to let the guest have writeable access to system tables, so the
>>> guest must relinquish write access to the frames wishing to be used as
>>> LDTs or GDTs.)
>>>
>>> The hypercall acts on the frame, not a virtual address, so either alias
>>> should be fine here.
>>>
>>> Under this new scheme, there will be two read-only aliases.  I guess
>>> this is easier to maintain the split consistently across Linux, than to
>>> special case Xen PV because it doesn't need the second alias.
>>>
>> I think we would gain nothing at all by special-casing Xen PV -- Linux
>> allocates the fixmap vaddrs at compile time, so we'd still allocate
>> them even if we rejigger all the helpers to avoid using them.
>>
> I don't have any experience with Xen so it would be great if virtme can test 
> it.


I am pretty sure I tested this series at some point but I'll test it again.

-boris


>
> I can remove the unused functions, I just thought they were useful
> shortcuts given some of them are already used.
>
>> --Andy
>
>


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

Re: [Xen-devel] [PATCH v5 2/3] x86: Remap GDT tables in the Fixmap section

[Thomas Garnier]

On Thu, Mar 9, 2017 at 1:46 PM, Andy Lutomirski  wrote:
> On Thu, Mar 9, 2017 at 1:43 PM, Andrew Cooper  
> wrote:
>> On 09/03/2017 21:32, Andy Lutomirski wrote:
>>> On Mon, Mar 6, 2017 at 2:03 PM, Thomas Garnier  wrote:
>>>
 --- a/arch/x86/xen/enlighten.c
 +++ b/arch/x86/xen/enlighten.c
 @@ -710,7 +710,7 @@ static void load_TLS_descriptor(struct thread_struct 
 *t,

 *shadow = t->tls_array[i];

 -   gdt = get_cpu_gdt_table(cpu);
 +   gdt = get_cpu_gdt_rw(cpu);
 maddr = arbitrary_virt_to_machine([GDT_ENTRY_TLS_MIN+i]);
 mc = __xen_mc_entry(0);
>>> Boris, is this right?  I don't see why it wouldn't be, but Xen is special.
>>
>> Under Xen PV, the GDT is already read-only at this point.  (It is not
>> safe to let the guest have writeable access to system tables, so the
>> guest must relinquish write access to the frames wishing to be used as
>> LDTs or GDTs.)
>>
>> The hypercall acts on the frame, not a virtual address, so either alias
>> should be fine here.
>>
>> Under this new scheme, there will be two read-only aliases.  I guess
>> this is easier to maintain the split consistently across Linux, than to
>> special case Xen PV because it doesn't need the second alias.
>>
>
> I think we would gain nothing at all by special-casing Xen PV -- Linux
> allocates the fixmap vaddrs at compile time, so we'd still allocate
> them even if we rejigger all the helpers to avoid using them.
>

I don't have any experience with Xen so it would be great if virtme can test it.

I can remove the unused functions, I just thought they were useful
shortcuts given some of them are already used.

> --Andy



-- 
Thomas

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

Re: [Xen-devel] [PATCH v5 2/3] x86: Remap GDT tables in the Fixmap section

[Andy Lutomirski]

On Thu, Mar 9, 2017 at 1:43 PM, Andrew Cooper  wrote:
> On 09/03/2017 21:32, Andy Lutomirski wrote:
>> On Mon, Mar 6, 2017 at 2:03 PM, Thomas Garnier  wrote:
>>
>>> --- a/arch/x86/xen/enlighten.c
>>> +++ b/arch/x86/xen/enlighten.c
>>> @@ -710,7 +710,7 @@ static void load_TLS_descriptor(struct thread_struct *t,
>>>
>>> *shadow = t->tls_array[i];
>>>
>>> -   gdt = get_cpu_gdt_table(cpu);
>>> +   gdt = get_cpu_gdt_rw(cpu);
>>> maddr = arbitrary_virt_to_machine([GDT_ENTRY_TLS_MIN+i]);
>>> mc = __xen_mc_entry(0);
>> Boris, is this right?  I don't see why it wouldn't be, but Xen is special.
>
> Under Xen PV, the GDT is already read-only at this point.  (It is not
> safe to let the guest have writeable access to system tables, so the
> guest must relinquish write access to the frames wishing to be used as
> LDTs or GDTs.)
>
> The hypercall acts on the frame, not a virtual address, so either alias
> should be fine here.
>
> Under this new scheme, there will be two read-only aliases.  I guess
> this is easier to maintain the split consistently across Linux, than to
> special case Xen PV because it doesn't need the second alias.
>

I think we would gain nothing at all by special-casing Xen PV -- Linux
allocates the fixmap vaddrs at compile time, so we'd still allocate
them even if we rejigger all the helpers to avoid using them.

--Andy

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

Re: [Xen-devel] [PATCH v5 2/3] x86: Remap GDT tables in the Fixmap section

[Andrew Cooper]

On 09/03/2017 21:32, Andy Lutomirski wrote:
> On Mon, Mar 6, 2017 at 2:03 PM, Thomas Garnier  wrote:
>
>> --- a/arch/x86/xen/enlighten.c
>> +++ b/arch/x86/xen/enlighten.c
>> @@ -710,7 +710,7 @@ static void load_TLS_descriptor(struct thread_struct *t,
>>
>> *shadow = t->tls_array[i];
>>
>> -   gdt = get_cpu_gdt_table(cpu);
>> +   gdt = get_cpu_gdt_rw(cpu);
>> maddr = arbitrary_virt_to_machine([GDT_ENTRY_TLS_MIN+i]);
>> mc = __xen_mc_entry(0);
> Boris, is this right?  I don't see why it wouldn't be, but Xen is special.

Under Xen PV, the GDT is already read-only at this point.  (It is not
safe to let the guest have writeable access to system tables, so the
guest must relinquish write access to the frames wishing to be used as
LDTs or GDTs.)

The hypercall acts on the frame, not a virtual address, so either alias
should be fine here.

Under this new scheme, there will be two read-only aliases.  I guess
this is easier to maintain the split consistently across Linux, than to
special case Xen PV because it doesn't need the second alias.

~Andrew

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

Re: [Xen-devel] [PATCH v5 3/3] x86: Make the GDT remapping read-only on 64-bit

[Andy Lutomirski]

On Mon, Mar 6, 2017 at 2:03 PM, Thomas Garnier  wrote:
> This patch makes the GDT remapped pages read-only to prevent corruption.
> This change is done only on 64-bit.
>
> The native_load_tr_desc function was adapted to correctly handle a
> read-only GDT. The LTR instruction always writes to the GDT TSS entry.
> This generates a page fault if the GDT is read-only. This change checks
> if the current GDT is a remap and swap GDTs as needed. This function was
> tested by booting multiple machines and checking hibernation works
> properly.
>
> KVM SVM and VMX were adapted to use the writeable GDT. On VMX, the
> per-cpu variable was removed for functions to fetch the original GDT.
> Instead of reloading the previous GDT, VMX will reload the fixmap GDT as
> expected. For testing, VMs were started and restored on multiple
> configurations.

I like this patch.

> +
> +/*
> + * The LTR instruction marks the TSS GDT entry as busy. On 64-bit, the GDT is
> + * a read-only remapping. To prevent a page fault, the GDT is switched to the
> + * original writeable version when needed.
> + */
> +#ifdef CONFIG_X86_64
>  static inline void native_load_tr_desc(void)
>  {
> +   struct desc_ptr gdt;
> +   int cpu = raw_smp_processor_id();
> +   bool restore = 0;
> +   struct desc_struct *fixmap_gdt;
> +
> +   native_store_gdt();

This part will slow this function down considerably, but with the
recent KVM improvements, I think that there are no callers left that
care about performance, so this should be fine.

--Andy

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

Re: [Xen-devel] [PATCH v5 2/3] x86: Remap GDT tables in the Fixmap section

[Andy Lutomirski]

On Mon, Mar 6, 2017 at 2:03 PM, Thomas Garnier  wrote:
> Each processor holds a GDT in its per-cpu structure. The sgdt
> instruction gives the base address of the current GDT. This address can
> be used to bypass KASLR memory randomization. With another bug, an
> attacker could target other per-cpu structures or deduce the base of
> the main memory section (PAGE_OFFSET).
>
> This patch relocates the GDT table for each processor inside the
> Fixmap section. The space is reserved based on number of supported
> processors.
>
> For consistency, the remapping is done by default on 32 and 64-bit.
>
> Each processor switches to its remapped GDT at the end of
> initialization. For hibernation, the main processor returns with the
> original GDT and switches back to the remapping at completion.
>
> This patch was tested on both architectures. Hibernation and KVM were
> both tested specially for their usage of the GDT.

Looks good with minor nitpicks.  Also, have you tested on Xen PV?

(If you aren't set up for it, virtme can do this test quite easily.  I
could run it for you if you like, too.)

> +static inline unsigned long get_current_gdt_rw_vaddr(void)
> +{
> +   return (unsigned long)get_current_gdt_rw();
> +}

This has no callers, so let's remove it.

> +static inline unsigned long get_cpu_gdt_ro_vaddr(int cpu)
> +{
> +   return (unsigned long)get_cpu_gdt_ro(cpu);
> +}

Ditto.

> +static inline unsigned long get_current_gdt_ro_vaddr(void)
> +{
> +   return (unsigned long)get_current_gdt_ro();
> +}

Ditto.

> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -710,7 +710,7 @@ static void load_TLS_descriptor(struct thread_struct *t,
>
> *shadow = t->tls_array[i];
>
> -   gdt = get_cpu_gdt_table(cpu);
> +   gdt = get_cpu_gdt_rw(cpu);
> maddr = arbitrary_virt_to_machine([GDT_ENTRY_TLS_MIN+i]);
> mc = __xen_mc_entry(0);

Boris, is this right?  I don't see why it wouldn't be, but Xen is special.

> @@ -504,7 +504,7 @@ void __init lguest_arch_host_init(void)
>  * byte, not the size, hence the "-1").
>  */
> state->host_gdt_desc.size = GDT_SIZE-1;
> -   state->host_gdt_desc.address = (long)get_cpu_gdt_table(i);
> +   state->host_gdt_desc.address = (long)get_cpu_gdt_rw(i);

I suspect this should be get_cpu_gdt_ro(), but I don't know too much
about lguest.  Hmm, maybe the right thing to do is to give lguest a
nice farewell and retire it.  The last time I tried to test it, I gave
up.


--Andy

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   5 xen-buildfail   never pass
 build-arm64-pvops 5 kernel-build fail   never pass
 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  9dc1e0cd81ee469d638d1962a92d9b4bd2972bfa
baseline version:
 xen  5d99933e6e3e54da3c7291a0f4bf6c89685b4d24

Last test of basis   106569  2017-03-09 17:01:14 Z0 days
Testing same since   106573  2017-03-09 19:01:04 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  George Dunlap 

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



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=9dc1e0cd81ee469d638d1962a92d9b4bd2972bfa
+ . ./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 
9dc1e0cd81ee469d638d1962a92d9b4bd2972bfa
+ branch=xen-unstable-smoke
+ revision=9dc1e0cd81ee469d638d1962a92d9b4bd2972bfa
+ . ./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.8-testing
+ '[' x9dc1e0cd81ee469d638d1962a92d9b4bd2972bfa = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : 

Re: [Xen-devel] [PATCH net v3] xen-netback: fix race condition on XenBus disconnect

[Paul Durrant]

> -Original Message-
> From: Igor Druzhinin [mailto:igor.druzhi...@citrix.com]
> Sent: 09 March 2017 19:42
> To: net...@vger.kernel.org; xen-de...@lists.xenproject.org
> Cc: Paul Durrant ; jgr...@suse.com; Wei Liu
> ; Igor Druzhinin 
> Subject: [PATCH net v3] xen-netback: fix race condition on XenBus
> disconnect
> 
> In some cases during XenBus disconnect event handling and subsequent
> queue resource release there may be some TX handlers active on
> other processors. Use RCU in order to synchronize with them.
> 
> Signed-off-by: Igor Druzhinin 

Reviewed-by: Paul Durrant 

> ---
> v3:
>  * Fix unintended semantic change in xenvif_get_ethtool_stats
>  * Dropped extra code
> 
> v2:
>  * Add protection for xenvif_get_ethtool_stats
>  * Additional comments and fixes
> ---
>  drivers/net/xen-netback/interface.c | 26 +-
>  drivers/net/xen-netback/netback.c   |  2 +-
>  drivers/net/xen-netback/xenbus.c| 20 ++--
>  3 files changed, 28 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-
> netback/interface.c
> index 829b26c..a3c018e 100644
> --- a/drivers/net/xen-netback/interface.c
> +++ b/drivers/net/xen-netback/interface.c
> @@ -165,13 +165,17 @@ static int xenvif_start_xmit(struct sk_buff *skb,
> struct net_device *dev)
>  {
>   struct xenvif *vif = netdev_priv(dev);
>   struct xenvif_queue *queue = NULL;
> - unsigned int num_queues = vif->num_queues;
> + unsigned int num_queues;
>   u16 index;
>   struct xenvif_rx_cb *cb;
> 
>   BUG_ON(skb->dev != dev);
> 
> - /* Drop the packet if queues are not set up */
> + /* Drop the packet if queues are not set up.
> +  * This handler should be called inside an RCU read section
> +  * so we don't need to enter it here explicitly.
> +  */
> + num_queues = rcu_dereference(vif)->num_queues;
>   if (num_queues < 1)
>   goto drop;
> 
> @@ -222,18 +226,18 @@ static struct net_device_stats
> *xenvif_get_stats(struct net_device *dev)
>  {
>   struct xenvif *vif = netdev_priv(dev);
>   struct xenvif_queue *queue = NULL;
> + unsigned int num_queues;
>   u64 rx_bytes = 0;
>   u64 rx_packets = 0;
>   u64 tx_bytes = 0;
>   u64 tx_packets = 0;
>   unsigned int index;
> 
> - spin_lock(>lock);
> - if (vif->queues == NULL)
> - goto out;
> + rcu_read_lock();
> + num_queues = rcu_dereference(vif)->num_queues;
> 
>   /* Aggregate tx and rx stats from each queue */
> - for (index = 0; index < vif->num_queues; ++index) {
> + for (index = 0; index < num_queues; ++index) {
>   queue = >queues[index];
>   rx_bytes += queue->stats.rx_bytes;
>   rx_packets += queue->stats.rx_packets;
> @@ -241,8 +245,7 @@ static struct net_device_stats
> *xenvif_get_stats(struct net_device *dev)
>   tx_packets += queue->stats.tx_packets;
>   }
> 
> -out:
> - spin_unlock(>lock);
> + rcu_read_unlock();
> 
>   vif->dev->stats.rx_bytes = rx_bytes;
>   vif->dev->stats.rx_packets = rx_packets;
> @@ -378,10 +381,13 @@ static void xenvif_get_ethtool_stats(struct
> net_device *dev,
>struct ethtool_stats *stats, u64 * data)
>  {
>   struct xenvif *vif = netdev_priv(dev);
> - unsigned int num_queues = vif->num_queues;
> + unsigned int num_queues;
>   int i;
>   unsigned int queue_index;
> 
> + rcu_read_lock();
> + num_queues = rcu_dereference(vif)->num_queues;
> +
>   for (i = 0; i < ARRAY_SIZE(xenvif_stats); i++) {
>   unsigned long accum = 0;
>   for (queue_index = 0; queue_index < num_queues;
> ++queue_index) {
> @@ -390,6 +396,8 @@ static void xenvif_get_ethtool_stats(struct
> net_device *dev,
>   }
>   data[i] = accum;
>   }
> +
> + rcu_read_unlock();
>  }
> 
>  static void xenvif_get_strings(struct net_device *dev, u32 stringset, u8 *
> data)
> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-
> netback/netback.c
> index f9bcf4a..602d408 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -214,7 +214,7 @@ static void xenvif_fatal_tx_err(struct xenvif *vif)
>   netdev_err(vif->dev, "fatal error; disabling device\n");
>   vif->disabled = true;
>   /* Disable the vif from queue 0's kthread */
> - if (vif->queues)
> + if (vif->num_queues)
>   xenvif_kick_thread(>queues[0]);
>  }
> 
> diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-
> netback/xenbus.c
> index d2d7cd9..a56d3ea 100644
> --- a/drivers/net/xen-netback/xenbus.c
> +++ b/drivers/net/xen-netback/xenbus.c
> @@ -495,26 +495,26 @@ static void backend_disconnect(struct
> backend_info *be)
>   struct xenvif 

Re: [Xen-devel] [PATCH v16 4/9] x86: add multiboot2 protocol support for EFI platforms

[Doug Goldstein]

On 3/7/17 9:44 PM, Konrad Rzeszutek Wilk wrote:
> On Tue, Mar 07, 2017 at 12:39:04AM +0100, Daniel Kiper wrote:
>> On Wed, Feb 22, 2017 at 09:04:17AM -0800, Doug Goldstein wrote:
>>
>> [...]
>>
>>> I'm currently at ELC and then on vacation so I don't have access to any
>>> of the machines currently myself. However the machine I most use to test
>>> is a NUC5i5MYHE and a NUC5i3MYHE if you want to ask around if someone
>>> has one internally. But that's why I gave QEMU as an example.
>>>
>>> I was using qemu master from a few weeks ago. I'll have to find the
>>> revision for you. But the command line I use is:
>>>
>>> -enable-kvm -M pc-q35-2.8 -device intel-iommu -cpu host -m 2048 -smp 2
>>> -drive if=pflash,format=raw,file=/tmp/tmp.EiR6ixmYzV -global
>>> isa-debugcon.iobase=0x402 -debugcon file:/tmp/tmp.nuvEXUWfnA -monitor
>>> stdio -chardev socket,host=127.0.0.1,port=25914,id=S0,server,nowait
>>> -device isa-serial,chardev=S0 -device piix3-usb-uhci -device usb-tablet
>>> -netdev id=net0,type=tap -device
>>> virtio-net-pci,netdev=net0,mac=52:54:00:12:34:56 -boot order=n -device
>>> qxl-vga -gdb tcp::14952
>>
>> Sadly, my colleagues and I are not able to reproduce the problem on any of
>> machines available for us (available on the market and some development
>> stuff in our labs). I did tests with QEMU (I am not able to run it with
>> "-device intel-iommu" on my machine; I have to investigate this). Everything
>> works. Joao did some tests on Intel NUC D34010WYK second generation.
>> Everything works. So, Konrad ordered Intel NUC NUC5i3MYHE for me. I am
>> waiting for delivery. Doug, could you tell me what distro, Xen, etc. you
>> have installed on that NUC? I would like to test same config as yours on
>> this machine.
> 
> I had a chat with Doug on IRC and:
>  - I had tested earlier on AMD, while he has only Intel boxes,
>  - He was wondering if this was an IOMMU issue.
> 
> So to double-check that, I installed Ubuntu 16.10 on my X11SAE
> SuperMicro, which has an Haswell E3-1245 v5 and with IOMMU enabled.
> 
> I tested the 'origin/staging' xen.gz build with the upstream grub2
> (I just used the 'master' branch) first and also just booting xen.efi.
> 
> Both worked fine.

Well if this was really the IOMMU issue then there's already a patch in
staging which noops out part of the memory allocator from the first part
of the series that was causing problems.

> 
> Then I used v16 of Daniel's patches (this thread). They are also
> now ongit://xenbits.xen.org/people/konradwilk/xen.git mb2.v16
> also the same way - as xen.efi and then using grub.efi and booting it
> (see below)
> 
> All worked fine.



> 
> konrad-Super-Server login: [  188.181526] reboot: Restarting system
> (XEN) Hardware Dom0 shutdown: rebooting machine
> (XEN) APIC error on CPU0: 40(00)
> 
> ... reboot.

So as I've mentioned you have to run 'xl info' and look at nr_cpus to
see the issue.



>  Starting Notify bootloader 
> tha[^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G  OK  ] Started 
> Notify bootloader that boot was successful.
> 
> Ubuntu 16.10 konrad-Super-Server hvc0
> 
> konrad-Super-Server login: 
> 

Still missing 'xl info'.


-- 
Doug Goldstein



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

[Xen-devel] [PATCH net v3] xen-netback: fix race condition on XenBus disconnect

[Igor Druzhinin]

In some cases during XenBus disconnect event handling and subsequent
queue resource release there may be some TX handlers active on
other processors. Use RCU in order to synchronize with them.

Signed-off-by: Igor Druzhinin 
---
v3:
 * Fix unintended semantic change in xenvif_get_ethtool_stats
 * Dropped extra code

v2:
 * Add protection for xenvif_get_ethtool_stats
 * Additional comments and fixes
---
 drivers/net/xen-netback/interface.c | 26 +-
 drivers/net/xen-netback/netback.c   |  2 +-
 drivers/net/xen-netback/xenbus.c| 20 ++--
 3 files changed, 28 insertions(+), 20 deletions(-)

diff --git a/drivers/net/xen-netback/interface.c 
b/drivers/net/xen-netback/interface.c
index 829b26c..a3c018e 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -165,13 +165,17 @@ static int xenvif_start_xmit(struct sk_buff *skb, struct 
net_device *dev)
 {
struct xenvif *vif = netdev_priv(dev);
struct xenvif_queue *queue = NULL;
-   unsigned int num_queues = vif->num_queues;
+   unsigned int num_queues;
u16 index;
struct xenvif_rx_cb *cb;
 
BUG_ON(skb->dev != dev);
 
-   /* Drop the packet if queues are not set up */
+   /* Drop the packet if queues are not set up.
+* This handler should be called inside an RCU read section
+* so we don't need to enter it here explicitly.
+*/
+   num_queues = rcu_dereference(vif)->num_queues;
if (num_queues < 1)
goto drop;
 
@@ -222,18 +226,18 @@ static struct net_device_stats *xenvif_get_stats(struct 
net_device *dev)
 {
struct xenvif *vif = netdev_priv(dev);
struct xenvif_queue *queue = NULL;
+   unsigned int num_queues;
u64 rx_bytes = 0;
u64 rx_packets = 0;
u64 tx_bytes = 0;
u64 tx_packets = 0;
unsigned int index;
 
-   spin_lock(>lock);
-   if (vif->queues == NULL)
-   goto out;
+   rcu_read_lock();
+   num_queues = rcu_dereference(vif)->num_queues;
 
/* Aggregate tx and rx stats from each queue */
-   for (index = 0; index < vif->num_queues; ++index) {
+   for (index = 0; index < num_queues; ++index) {
queue = >queues[index];
rx_bytes += queue->stats.rx_bytes;
rx_packets += queue->stats.rx_packets;
@@ -241,8 +245,7 @@ static struct net_device_stats *xenvif_get_stats(struct 
net_device *dev)
tx_packets += queue->stats.tx_packets;
}
 
-out:
-   spin_unlock(>lock);
+   rcu_read_unlock();
 
vif->dev->stats.rx_bytes = rx_bytes;
vif->dev->stats.rx_packets = rx_packets;
@@ -378,10 +381,13 @@ static void xenvif_get_ethtool_stats(struct net_device 
*dev,
 struct ethtool_stats *stats, u64 * data)
 {
struct xenvif *vif = netdev_priv(dev);
-   unsigned int num_queues = vif->num_queues;
+   unsigned int num_queues;
int i;
unsigned int queue_index;
 
+   rcu_read_lock();
+   num_queues = rcu_dereference(vif)->num_queues;
+
for (i = 0; i < ARRAY_SIZE(xenvif_stats); i++) {
unsigned long accum = 0;
for (queue_index = 0; queue_index < num_queues; ++queue_index) {
@@ -390,6 +396,8 @@ static void xenvif_get_ethtool_stats(struct net_device *dev,
}
data[i] = accum;
}
+
+   rcu_read_unlock();
 }
 
 static void xenvif_get_strings(struct net_device *dev, u32 stringset, u8 * 
data)
diff --git a/drivers/net/xen-netback/netback.c 
b/drivers/net/xen-netback/netback.c
index f9bcf4a..602d408 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -214,7 +214,7 @@ static void xenvif_fatal_tx_err(struct xenvif *vif)
netdev_err(vif->dev, "fatal error; disabling device\n");
vif->disabled = true;
/* Disable the vif from queue 0's kthread */
-   if (vif->queues)
+   if (vif->num_queues)
xenvif_kick_thread(>queues[0]);
 }
 
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index d2d7cd9..a56d3ea 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -495,26 +495,26 @@ static void backend_disconnect(struct backend_info *be)
struct xenvif *vif = be->vif;
 
if (vif) {
+   unsigned int num_queues = vif->num_queues;
unsigned int queue_index;
-   struct xenvif_queue *queues;
 
xen_unregister_watchers(vif);
 #ifdef CONFIG_DEBUG_FS
xenvif_debugfs_delif(vif);
 #endif /* CONFIG_DEBUG_FS */
xenvif_disconnect_data(vif);
-   for (queue_index = 0;
-queue_index < vif->num_queues;
-++queue_index)
-   xenvif_deinit_queue(>queues[queue_index]);
 
-  

Re: [Xen-devel] [Qemu-devel] [PATCH] xen: don't save/restore the physmap on VM save/restore

[no-reply]

Hi,

This series failed automatic build test. Please find the testing commands and
their output below. If you have docker installed, you can probably reproduce it
locally.

Type: series
Subject: [Qemu-devel] [PATCH] xen: don't save/restore the physmap on VM 
save/restore
Message-id: 1489084689-19008-1-git-send-email-igor.druzhi...@citrix.com

=== TEST SCRIPT BEGIN ===
#!/bin/bash
set -e
git submodule update --init dtc
# Let docker tests dump environment info
export SHOW_ENV=1
export J=16
make docker-test-quick@centos6
make docker-test-mingw@fedora
make docker-test-build@min-glib
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
ebd2fd8 xen: don't save/restore the physmap on VM save/restore

=== OUTPUT BEGIN ===
Submodule 'dtc' (git://git.qemu-project.org/dtc.git) registered for path 'dtc'
Cloning into 'dtc'...
Submodule path 'dtc': checked out 'fa8bc7f928ac25f23532afc8beb2073efc8fb063'
  BUILD   centos6
make[1]: Entering directory `/var/tmp/patchew-tester-tmp-o3dzprlk/src'
  ARCHIVE qemu.tgz
  ARCHIVE dtc.tgz
  COPYRUNNER
RUN test-quick in qemu:centos6 
Packages installed:
SDL-devel-1.2.14-7.el6_7.1.x86_64
ccache-3.1.6-2.el6.x86_64
epel-release-6-8.noarch
gcc-4.4.7-17.el6.x86_64
git-1.7.1-4.el6_7.1.x86_64
glib2-devel-2.28.8-5.el6.x86_64
libfdt-devel-1.4.0-1.el6.x86_64
make-3.81-23.el6.x86_64
package g++ is not installed
pixman-devel-0.32.8-1.el6.x86_64
tar-1.23-15.el6_8.x86_64
zlib-devel-1.2.3-29.el6.x86_64

Environment variables:
PACKAGES=libfdt-devel ccache tar git make gcc g++ zlib-devel 
glib2-devel SDL-devel pixman-devel epel-release
HOSTNAME=ac1377aa9f68
TERM=xterm
MAKEFLAGS= -j16
HISTSIZE=1000
J=16
USER=root
CCACHE_DIR=/var/tmp/ccache
EXTRA_CONFIGURE_OPTS=
V=
SHOW_ENV=1
MAIL=/var/spool/mail/root
PATH=/usr/lib/ccache:/usr/lib64/ccache:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PWD=/
LANG=en_US.UTF-8
TARGET_LIST=
HISTCONTROL=ignoredups
SHLVL=1
HOME=/root
TEST_DIR=/tmp/qemu-test
LOGNAME=root
LESSOPEN=||/usr/bin/lesspipe.sh %s
FEATURES= dtc
DEBUG=
G_BROKEN_FILENAMES=1
CCACHE_HASHDIR=
_=/usr/bin/env

Configure options:
--enable-werror --target-list=x86_64-softmmu,aarch64-softmmu 
--prefix=/var/tmp/qemu-build/install
No C++ compiler available; disabling C++ specific optional code
Install prefix/var/tmp/qemu-build/install
BIOS directory/var/tmp/qemu-build/install/share/qemu
binary directory  /var/tmp/qemu-build/install/bin
library directory /var/tmp/qemu-build/install/lib
module directory  /var/tmp/qemu-build/install/lib/qemu
libexec directory /var/tmp/qemu-build/install/libexec
include directory /var/tmp/qemu-build/install/include
config directory  /var/tmp/qemu-build/install/etc
local state directory   /var/tmp/qemu-build/install/var
Manual directory  /var/tmp/qemu-build/install/share/man
ELF interp prefix /usr/gnemul/qemu-%M
Source path   /tmp/qemu-test/src
C compilercc
Host C compiler   cc
C++ compiler  
Objective-C compiler cc
ARFLAGS   rv
CFLAGS-O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g 
QEMU_CFLAGS   -I/usr/include/pixman-1   -I$(SRC_PATH)/dtc/libfdt -pthread 
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include   -fPIE -DPIE -m64 -mcx16 
-D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes 
-Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes 
-fno-strict-aliasing -fno-common -fwrapv  -Wendif-labels 
-Wno-missing-include-dirs -Wempty-body -Wnested-externs -Wformat-security 
-Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration 
-Wold-style-definition -Wtype-limits -fstack-protector-all
LDFLAGS   -Wl,--warn-common -Wl,-z,relro -Wl,-z,now -pie -m64 -g 
make  make
install   install
pythonpython -B
smbd  /usr/sbin/smbd
module supportno
host CPU  x86_64
host big endian   no
target list   x86_64-softmmu aarch64-softmmu
tcg debug enabled no
gprof enabled no
sparse enabledno
strip binariesyes
profiler  no
static build  no
pixmansystem
SDL support   yes (1.2.14)
GTK support   no 
GTK GL supportno
VTE support   no 
TLS priority  NORMAL
GNUTLS supportno
GNUTLS rndno
libgcrypt no
libgcrypt kdf no
nettleno 
nettle kdfno
libtasn1  no
curses supportno
virgl support no
curl support  no
mingw32 support   no
Audio drivers oss
Block whitelist (rw) 
Block whitelist (ro) 
VirtFS supportno
VNC support   yes
VNC SASL support  no
VNC JPEG support  no
VNC PNG support   no
xen support   no
brlapi supportno
bluez  supportno
Documentation no
PIE   yes
vde support   no
netmap supportno
Linux AIO support no
ATTR/XATTR support yes
Install blobs yes
KVM support   yes
HAX support   no
RDMA support  no
TCG interpreter   no
fdt support   yes
preadv supportyes
fdatasync 

Re: [Xen-devel] [Qemu-devel] [PATCH] xen: don't save/restore the physmap on VM save/restore

[no-reply]

Hi,

This series seems to have some coding style problems. See output below for
more information:

Type: series
Subject: [Qemu-devel] [PATCH] xen: don't save/restore the physmap on VM 
save/restore
Message-id: 1489084689-19008-1-git-send-email-igor.druzhi...@citrix.com

=== TEST SCRIPT BEGIN ===
#!/bin/bash

BASE=base
n=1
total=$(git log --oneline $BASE.. | wc -l)
failed=0

# Useful git options
git config --local diff.renamelimit 0
git config --local diff.renames True

commits="$(git log --format=%H --reverse $BASE..)"
for c in $commits; do
echo "Checking PATCH $n/$total: $(git log -n 1 --format=%s $c)..."
if ! git show $c --format=email | ./scripts/checkpatch.pl --mailback -; then
failed=1
echo
fi
n=$((n+1))
done

exit $failed
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 * [new tag] 
patchew/1489084689-19008-1-git-send-email-igor.druzhi...@citrix.com -> 
patchew/1489084689-19008-1-git-send-email-igor.druzhi...@citrix.com
Switched to a new branch 'test'
ebd2fd8 xen: don't save/restore the physmap on VM save/restore

=== OUTPUT BEGIN ===
Checking PATCH 1/1: xen: don't save/restore the physmap on VM save/restore...
ERROR: space prohibited between function name and open parenthesis '('
#105: FILE: xen-hvm.c:344:
+physmap = g_malloc(sizeof (XenPhysmap));

ERROR: that open brace { should be on the previous line
#114: FILE: xen-hvm.c:353:
+if (runstate_check(RUN_STATE_INMIGRATE))
+{

ERROR: trailing whitespace
#117: FILE: xen-hvm.c:356:
+ * established during the restore phase so we can safely update the $

ERROR: braces {} are necessary for all arms of this statement
#119: FILE: xen-hvm.c:358:
+ if (mr == framebuffer)
[...]

total: 4 errors, 0 warnings, 196 lines checked

Your patch has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

=== OUTPUT END ===

Test command exited with code: 1


---
Email generated automatically by Patchew [http://patchew.org/].
Please send your feedback to patchew-de...@freelists.org
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH RFC v3 7/8] golang/xenlight: Implement libxl_scheduler enumeration

[Ronald Rojas]

Include both constants and a Stringification for libxl_scheduler.

Signed-off-by: George Dunlap 
Signed-off-by: Ronald Rojas 
---

CC: xen-devel@lists.xen.org
CC: george.dun...@citrix.com
CC: ian.jack...@eu.citrix.com
CC: wei.l...@citrix.com
---
---
 tools/golang/xenlight/xenlight.go | 62 +++
 1 file changed, 62 insertions(+)

diff --git a/tools/golang/xenlight/xenlight.go 
b/tools/golang/xenlight/xenlight.go
index eb2b3cf..d4a6bc1 100644
--- a/tools/golang/xenlight/xenlight.go
+++ b/tools/golang/xenlight/xenlight.go
@@ -311,6 +311,68 @@ func (cdi *C.libxl_dominfo) toGo() (di *Dominfo) {
return
 }
 
+// # Consistent with values defined in domctl.h
+// # Except unknown which we have made up
+// libxl_scheduler = Enumeration("scheduler", [
+// (0, "unknown"),
+// (4, "sedf"),
+// (5, "credit"),
+// (6, "credit2"),
+// (7, "arinc653"),
+// (8, "rtds"),
+// ])
+type Scheduler int
+
+var (
+   SchedulerUnknown  Scheduler = C.LIBXL_SCHEDULER_UNKNOWN
+   SchedulerSedf Scheduler = C.LIBXL_SCHEDULER_SEDF
+   SchedulerCredit   Scheduler = C.LIBXL_SCHEDULER_CREDIT
+   SchedulerCredit2  Scheduler = C.LIBXL_SCHEDULER_CREDIT2
+   SchedulerArinc653 Scheduler = C.LIBXL_SCHEDULER_ARINC653
+   SchedulerRTDS Scheduler = C.LIBXL_SCHEDULER_RTDS
+)
+
+// const char *libxl_scheduler_to_string(libxl_scheduler p);
+func (s Scheduler) String() string {
+   cs := C.libxl_scheduler_to_string(C.libxl_scheduler(s))
+   // No need to free const return value
+
+   return C.GoString(cs)
+}
+
+// int libxl_scheduler_from_string(const char *s, libxl_scheduler *e);
+func (s *Scheduler) FromString(gstr string) (err error) {
+   cstr := C.CString(gstr)
+   defer C.free(unsafe.Pointer(cstr))
+
+   var cs C.libxl_scheduler
+   ret := C.libxl_scheduler_from_string(cstr, )
+   if ret != 0 {
+   err = Error(-ret)
+   return
+   }
+
+   *s = Scheduler(cs)
+   return
+}
+
+func SchedulerFromString(name string) (s Scheduler, err error) {
+   cname := C.CString(name)
+   defer C.free(unsafe.Pointer(cname))
+
+   var cs C.libxl_scheduler
+
+   ret := C.libxl_scheduler_from_string(cname, )
+   if ret != 0 {
+   err = Error(-ret)
+   return
+   }
+
+   s = Scheduler(cs)
+
+   return
+}
+
 /*
  * Bitmap operations
  */
-- 
2.7.3


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

[Xen-devel] [PATCH RFC v3 8/8] golang/xenlight: Implement cpupool operations

[Ronald Rojas]

Include some useful "Utility" functions:
- CpupoolFindByName
- CpupoolMakeFree

Still need to implement the following functions:
- libxl_cpupool_rename
- libxl_cpupool_cpuadd_node
- libxl_cpupool_cpuremove_node
- libxl_cpupool_movedomain

Signed-off-by: George Dunlap 
Signed-off-by: Ronald Rojas 
---

CC: xen-devel@lists.xen.org
CC: george.dun...@citrix.com
CC: ian.jack...@eu.citrix.com
CC: wei.l...@citrix.com
---
 tools/golang/xenlight/xenlight.go | 238 ++
 1 file changed, 238 insertions(+)

diff --git a/tools/golang/xenlight/xenlight.go 
b/tools/golang/xenlight/xenlight.go
index d4a6bc1..853a634 100644
--- a/tools/golang/xenlight/xenlight.go
+++ b/tools/golang/xenlight/xenlight.go
@@ -373,6 +373,244 @@ func SchedulerFromString(name string) (s Scheduler, err 
error) {
return
 }
 
+
+// libxl_cpupoolinfo = Struct("cpupoolinfo", [
+// ("poolid",  uint32),
+// ("pool_name",   string),
+// ("sched",   libxl_scheduler),
+// ("n_dom",   uint32),
+// ("cpumap",  libxl_bitmap)
+// ], dir=DIR_OUT)
+
+type CpupoolInfo struct {
+   Poolid  uint32
+   PoolNamestring
+   Scheduler   Scheduler
+   DomainCount int
+   Cpumap  Bitmap
+}
+
+func (cci C.libxl_cpupoolinfo)CToGo ()(gci CpupoolInfo) {
+   gci.Poolid = uint32(cci.poolid)
+   gci.PoolName = C.GoString(cci.pool_name)
+   gci.Scheduler = Scheduler(cci.sched)
+   gci.DomainCount = int(cci.n_dom)
+   gci.Cpumap = cci.cpumap.CToGo()
+
+   return
+}
+
+// libxl_cpupoolinfo * libxl_list_cpupool(libxl_ctx*, int *nb_pool_out);
+// void libxl_cpupoolinfo_list_free(libxl_cpupoolinfo *list, int nb_pool);
+func (Ctx *Context) ListCpupool() (list []CpupoolInfo) {
+   err := Ctx.CheckOpen()
+   if err != nil {
+   return
+   }
+
+   var nbPool C.int
+
+   c_cpupool_list := C.libxl_list_cpupool(Ctx.ctx, )
+
+   defer C.libxl_cpupoolinfo_list_free(c_cpupool_list, nbPool)
+
+   if int(nbPool) == 0 {
+   return
+   }
+
+   // Magic
+   cpupoolListSlice := (*[1 << 
30]C.libxl_cpupoolinfo)(unsafe.Pointer(c_cpupool_list))[:nbPool:nbPool]
+
+   for i := range cpupoolListSlice {
+   info := cpupoolListSlice[i].CToGo()
+
+   list = append(list, info)
+   }
+
+   return
+}
+
+// int libxl_cpupool_info(libxl_ctx *ctx, libxl_cpupoolinfo *info, uint32_t 
poolid);
+func (Ctx *Context) CpupoolInfo(Poolid uint32) (pool CpupoolInfo) {
+   err := Ctx.CheckOpen()
+   if err != nil {
+   return
+   }
+
+   var c_cpupool C.libxl_cpupoolinfo
+
+   ret := C.libxl_cpupool_info(Ctx.ctx, _cpupool, C.uint32_t(Poolid))
+   if ret != 0 {
+   err = Error(-ret)
+   return
+   }
+   defer C.libxl_cpupoolinfo_dispose(_cpupool)
+
+   pool = c_cpupool.CToGo()
+
+   return
+}
+
+// int libxl_cpupool_create(libxl_ctx *ctx, const char *name,
+//  libxl_scheduler sched,
+//  libxl_bitmap cpumap, libxl_uuid *uuid,
+//  uint32_t *poolid);
+// FIXME: uuid
+// FIXME: Setting poolid
+func (Ctx *Context) CpupoolCreate(Name string, Scheduler Scheduler, Cpumap 
Bitmap) (err error, Poolid uint32) {
+   err = Ctx.CheckOpen()
+   if err != nil {
+   return
+   }
+
+   poolid := C.uint32_t(0)
+   name := C.CString(Name)
+   defer C.free(unsafe.Pointer(name))
+
+   // For now, just do what xl does, and make a new uuid every time we 
create the pool
+   var uuid C.libxl_uuid
+   C.libxl_uuid_generate()
+
+   cbm := Cpumap.GoToC()
+   defer C.libxl_bitmap_dispose()
+
+   ret := C.libxl_cpupool_create(Ctx.ctx, name, 
C.libxl_scheduler(Scheduler),
+   cbm, , )
+   if ret != 0 {
+   err = Error(-ret)
+   return
+   }
+
+   Poolid = uint32(poolid)
+
+   return
+}
+
+// int libxl_cpupool_destroy(libxl_ctx *ctx, uint32_t poolid);
+func (Ctx *Context) CpupoolDestroy(Poolid uint32) (err error) {
+   err = Ctx.CheckOpen()
+   if err != nil {
+   return
+   }
+
+   ret := C.libxl_cpupool_destroy(Ctx.ctx, C.uint32_t(Poolid))
+   if ret != 0 {
+   err = Error(-ret)
+   return
+   }
+
+   return
+}
+
+// int libxl_cpupool_cpuadd(libxl_ctx *ctx, uint32_t poolid, int cpu);
+func (Ctx *Context) CpupoolCpuadd(Poolid uint32, Cpu int) (err error) {
+   err = Ctx.CheckOpen()
+   if err != nil {
+   return
+   }
+
+   ret := C.libxl_cpupool_cpuadd(Ctx.ctx, C.uint32_t(Poolid), C.int(Cpu))
+   if ret != 0 {
+   err = Error(-ret)
+   return
+   }
+
+   return
+}
+
+// int libxl_cpupool_cpuadd_cpumap(libxl_ctx *ctx, uint32_t poolid,
+// const libxl_bitmap 

[Xen-devel] [PATCH RFC v3 6/8] golang/xenlight: Implement libxl_bitmap and helper operations

[Ronald Rojas]

Implement Bitmap type, along with helper functions.

The Bitmap type is implemented interllay in a way which makes it
easy to copy into and out of the C libxl_bitmap type.

Signed-off-by: George Dunlap 
Signed-off-by: Ronald Rojas 

---

CC: xen-devel@lists.xen.org
CC: george.dun...@citrix.com
CC: ian.jack...@eu.citrix.com
CC: wei.l...@citrix.com

---
---
 tools/golang/xenlight/xenlight.go | 167 ++
 1 file changed, 167 insertions(+)

diff --git a/tools/golang/xenlight/xenlight.go 
b/tools/golang/xenlight/xenlight.go
index 34c3050..eb2b3cf 100644
--- a/tools/golang/xenlight/xenlight.go
+++ b/tools/golang/xenlight/xenlight.go
@@ -129,6 +129,20 @@ func (chwcap C.libxl_hwcap) toGo() (ghwcap Hwcap) {
return
 }
 
+// typedef struct {
+// uint32_t size;  /* number of bytes in map */
+// uint8_t *map;
+// } libxl_bitmap;
+
+// Implement the Go bitmap type such that the underlying data can
+// easily be copied in and out.  NB that we still have to do copies
+// both directions, because cgo runtime restrictions forbid passing to
+// a C function a pointer to a Go-allocated structure which contains a
+// pointer.
+type Bitmap struct {
+   bitmap []C.uint8_t
+}
+
 /*
  * Types: IDL
  *
@@ -298,6 +312,159 @@ func (cdi *C.libxl_dominfo) toGo() (di *Dominfo) {
 }
 
 /*
+ * Bitmap operations
+ */
+
+// Return a Go bitmap which is a copy of the referred C bitmap.
+func (cbm C.libxl_bitmap) toGo() (gbm Bitmap) {
+   // Alloc a Go slice for the bytes
+   size := int(cbm.size)
+   gbm.bitmap = make([]C.uint8_t, size)
+
+   // Make a slice pointing to the C array
+   mapslice := (*[1 << 30]C.uint8_t)(unsafe.Pointer(cbm._map))[:size:size]
+
+   // And copy the C array into the Go array
+   copy(gbm.bitmap, mapslice)
+
+   return
+}
+
+// Must be C.libxl_bitmap_dispose'd of afterwards
+func (gbm Bitmap) toC() (cbm C.libxl_bitmap) {
+   C.libxl_bitmap_init()
+
+   size := len(gbm.bitmap)
+   cbm._map = (*C.uint8_t)(C.malloc(C.size_t(size)))
+   cbm.size = C.uint32_t(size)
+   if cbm._map == nil {
+   panic("C.calloc failed!")
+   }
+
+   // Make a slice pointing to the C array
+   mapslice := (*[1 << 30]C.uint8_t)(unsafe.Pointer(cbm._map))[:size:size]
+
+   // And copy the Go array into the C array
+   copy(mapslice, gbm.bitmap)
+
+   return
+}
+
+func (bm *Bitmap) Test(bit int) bool {
+   ubit := uint(bit)
+   if bit > bm.Max() || bm.bitmap == nil {
+   return false
+   }
+
+   return (bm.bitmap[bit/8] & (1 << (ubit & 7))) != 0
+}
+
+func (bm *Bitmap) Set(bit int) {
+   ibit := bit / 8
+   if ibit+1 > len(bm.bitmap) {
+   bm.bitmap = append(bm.bitmap, make([]C.uint8_t, 
ibit+1-len(bm.bitmap))...)
+   }
+
+   bm.bitmap[ibit] |= 1 << (uint(bit) & 7)
+}
+
+func (bm *Bitmap) SetRange(start int, end int) {
+   for i := start; i <= end; i++ {
+   bm.Set(i)
+   }
+}
+
+func (bm *Bitmap) Clear(bit int) {
+   ubit := uint(bit)
+   if bit > bm.Max() || bm.bitmap == nil {
+   return
+   }
+
+   bm.bitmap[bit/8] &= ^(1 << (ubit & 7))
+}
+
+func (bm *Bitmap) ClearRange(start int, end int) {
+   for i := start; i <= end; i++ {
+   bm.Clear(i)
+   }
+}
+
+func (bm *Bitmap) Max() int {
+   return len(bm.bitmap)*8 - 1
+}
+
+func (bm *Bitmap) IsEmpty() bool {
+   for i := 0; i < len(bm.bitmap); i++ {
+   if bm.bitmap[i] != 0 {
+   return false
+   }
+   }
+   return true
+}
+
+func (a Bitmap) And(b Bitmap) (c Bitmap) {
+   var max, min int
+   if len(a.bitmap) > len(b.bitmap) {
+   max = len(a.bitmap)
+   min = len(b.bitmap)
+   } else {
+   max = len(b.bitmap)
+   min = len(a.bitmap)
+   }
+   c.bitmap = make([]C.uint8_t, max)
+
+   for i := 0; i < min; i++ {
+   c.bitmap[i] = a.bitmap[i] & b.bitmap[i]
+   }
+   return
+}
+
+func (bm Bitmap) String() (s string) {
+   lastOnline := false
+   crange := false
+   printed := false
+   var i int
+   /// --x-x-x -> 2,4-8,10
+   /// --x-xxx -> 2,4-10
+   for i = 0; i <= bm.Max(); i++ {
+   if bm.Test(i) {
+   if !lastOnline {
+   // Switching offline -> online, print this cpu
+   if printed {
+   s += ","
+   }
+   s += fmt.Sprintf("%d", i)
+   printed = true
+   } else if !crange {
+   // last was online, but we're not in a range; 
print -
+   crange = true
+   s += "-"
+   

[Xen-devel] [PATCH RFC v3 2/8] golang/xenlight: Add error constants and standard handling

[Ronald Rojas]

Create error type Errorxl for throwing proper xenlight
errors.

Update Ctx functions to throw Errorxl errors.

Signed-off-by: Ronald Rojas 
---

CC: xen-devel@lists.xen.org
CC: george.dun...@citrix.com
CC: ian.jack...@eu.citrix.com
CC: wei.l...@citrix.com
---
---
 tools/golang/xenlight/xenlight.go | 78 ++-
 1 file changed, 76 insertions(+), 2 deletions(-)

diff --git a/tools/golang/xenlight/xenlight.go 
b/tools/golang/xenlight/xenlight.go
index b025961..a99d9d3 100644
--- a/tools/golang/xenlight/xenlight.go
+++ b/tools/golang/xenlight/xenlight.go
@@ -37,8 +37,71 @@ import (
 )
 
 /*
+ * Errors
+ */
+
+type Error int
+
+const (
+   ErrorNonspecific  = Error(-C.ERROR_NONSPECIFIC)
+   ErrorVersion  = Error(-C.ERROR_VERSION)
+   ErrorFail = Error(-C.ERROR_FAIL)
+   ErrorNi   = Error(-C.ERROR_NI)
+   ErrorNomem= Error(-C.ERROR_NOMEM)
+   ErrorInval= Error(-C.ERROR_INVAL)
+   ErrorBadfail  = Error(-C.ERROR_BADFAIL)
+   ErrorGuestTimedout= Error(-C.ERROR_GUEST_TIMEDOUT)
+   ErrorTimedout = Error(-C.ERROR_TIMEDOUT)
+   ErrorNoparavirt   = Error(-C.ERROR_NOPARAVIRT)
+   ErrorNotReady = Error(-C.ERROR_NOT_READY)
+   ErrorOseventRegFail   = Error(-C.ERROR_OSEVENT_REG_FAIL)
+   ErrorBufferfull   = Error(-C.ERROR_BUFFERFULL)
+   ErrorUnknownChild = Error(-C.ERROR_UNKNOWN_CHILD)
+   ErrorLockFail = Error(-C.ERROR_LOCK_FAIL)
+   ErrorJsonConfigEmpty  = Error(-C.ERROR_JSON_CONFIG_EMPTY)
+   ErrorDeviceExists = Error(-C.ERROR_DEVICE_EXISTS)
+   ErrorCheckpointDevopsDoesNotMatch = 
Error(-C.ERROR_CHECKPOINT_DEVOPS_DOES_NOT_MATCH)
+   ErrorCheckpointDeviceNotSupported = 
Error(-C.ERROR_CHECKPOINT_DEVICE_NOT_SUPPORTED)
+   ErrorVnumaConfigInvalid   = Error(-C.ERROR_VNUMA_CONFIG_INVALID)
+   ErrorDomainNotfound   = Error(-C.ERROR_DOMAIN_NOTFOUND)
+   ErrorAborted  = Error(-C.ERROR_ABORTED)
+   ErrorNotfound = Error(-C.ERROR_NOTFOUND)
+   ErrorDomainDestroyed  = Error(-C.ERROR_DOMAIN_DESTROYED)
+   ErrorFeatureRemoved   = Error(-C.ERROR_FEATURE_REMOVED)
+)
+
+var errors = [...]string{
+   ErrorNonspecific:  "Non-specific error",
+   ErrorVersion:  "Wrong version",
+   ErrorFail: "Failed",
+   ErrorNi:   "Not Implemented",
+   ErrorNomem:"No memory",
+   ErrorInval:"Invalid argument",
+   ErrorBadfail:  "Bad Fail",
+   ErrorGuestTimedout:"Guest timed out",
+   ErrorTimedout: "Timed out",
+   ErrorNoparavirt:   "No Paravirtualization",
+   ErrorNotReady: "Not ready",
+   ErrorOseventRegFail:   "OS event registration failed",
+   ErrorBufferfull:   "Buffer full",
+   ErrorUnknownChild: "Unknown child",
+   ErrorLockFail: "Lock failed",
+   ErrorJsonConfigEmpty:  "JSON config empty",
+   ErrorDeviceExists: "Device exists",
+   ErrorCheckpointDevopsDoesNotMatch: "Checkpoint devops does not match",
+   ErrorCheckpointDeviceNotSupported: "Checkpoint device not supported",
+   ErrorVnumaConfigInvalid:   "VNUMA config invalid",
+   ErrorDomainNotfound:   "Domain not found",
+   ErrorAborted:  "Aborted",
+   ErrorNotfound: "Not found",
+   ErrorDomainDestroyed:  "Domain destroyed",
+   ErrorFeatureRemoved:   "Feature removed",
+}
+
+/*
  * Types: Builtins
  */
+
 type Context struct {
ctx *C.libxl_ctx
 }
@@ -50,6 +113,17 @@ var Ctx Context
 
 var logger *C.xentoollog_logger_stdiostream
 
+func (e Error) Error() string {
+   if 0 < int(e) && int(e) < len(errors) {
+   s := errors[e]
+   if s != "" {
+   return s
+   }
+   }
+   return fmt.Sprintf("libxl error: %d", -e)
+
+}
+
 func (Ctx *Context) IsOpen() bool {
return Ctx.ctx != nil
 }
@@ -64,7 +138,7 @@ func (Ctx *Context) Open() (err error) {
0, unsafe.Pointer(logger))
 
if ret != 0 {
-   err = fmt.Errorf("Error: %d", -ret)
+   err = Error(-ret)
}
return
 }
@@ -74,7 +148,7 @@ func (Ctx *Context) Close() (err error) {
Ctx.ctx = nil
 
if ret != 0 {
-   err = fmt.Errorf("Error: 

[Xen-devel] [PATCH RFC v3 5/8] golang/xenlight: Add tests host related functionality functions

[Ronald Rojas]

Create tests for the following functions:
- GetVersionInfo
- GetPhysinfo
- GetDominfo
- GetMaxCpus
- GetOnlineCpus
- GetMaxNodes
- GetFreeMemory

Signed-off-by: Ronald Rojas 
Signed-off-by: George Dunlap 

---
changes since last version

- created CFLAGS and LDLIBS variables to build test C
files with required dependencies.

- created create_context and destroy_context function
for tests to create/destroy libxl_ctx and xenlogger

- Formating changes

- Removed stale comments

- Removed redundant error checks in Golang tests

CC: xen-devel@lists.xen.org
CC: george.dun...@citrix.com
CC: ian.jack...@eu.citrix.com
CC: wei.l...@citrix.com
---
---
 tools/golang/xenlight/test/xeninfo/Makefile   | 41 +++
 tools/golang/xenlight/test/xeninfo/dominfo.c  | 33 ++
 tools/golang/xenlight/test/xeninfo/dominfo.go | 31 +
 tools/golang/xenlight/test/xeninfo/freememory.c   | 26 ++
 tools/golang/xenlight/test/xeninfo/freememory.go  | 25 ++
 tools/golang/xenlight/test/xeninfo/maxcpu.c   | 18 ++
 tools/golang/xenlight/test/xeninfo/maxcpu.go  | 24 +
 tools/golang/xenlight/test/xeninfo/maxnodes.c | 15 +
 tools/golang/xenlight/test/xeninfo/maxnodes.go| 24 +
 tools/golang/xenlight/test/xeninfo/onlinecpu.c| 18 ++
 tools/golang/xenlight/test/xeninfo/onlinecpu.go   | 24 +
 tools/golang/xenlight/test/xeninfo/physinfo.c | 32 ++
 tools/golang/xenlight/test/xeninfo/physinfo.go| 32 ++
 tools/golang/xenlight/test/xeninfo/print.h| 22 
 tools/golang/xenlight/test/xeninfo/versioninfo.c  | 22 
 tools/golang/xenlight/test/xeninfo/versioninfo.go | 28 
 tools/golang/xenlight/test/xeninfo/xenlight.go|  1 +
 17 files changed, 416 insertions(+)
 create mode 100644 tools/golang/xenlight/test/xeninfo/Makefile
 create mode 100644 tools/golang/xenlight/test/xeninfo/dominfo.c
 create mode 100644 tools/golang/xenlight/test/xeninfo/dominfo.go
 create mode 100644 tools/golang/xenlight/test/xeninfo/freememory.c
 create mode 100644 tools/golang/xenlight/test/xeninfo/freememory.go
 create mode 100644 tools/golang/xenlight/test/xeninfo/maxcpu.c
 create mode 100644 tools/golang/xenlight/test/xeninfo/maxcpu.go
 create mode 100644 tools/golang/xenlight/test/xeninfo/maxnodes.c
 create mode 100644 tools/golang/xenlight/test/xeninfo/maxnodes.go
 create mode 100644 tools/golang/xenlight/test/xeninfo/onlinecpu.c
 create mode 100644 tools/golang/xenlight/test/xeninfo/onlinecpu.go
 create mode 100644 tools/golang/xenlight/test/xeninfo/physinfo.c
 create mode 100644 tools/golang/xenlight/test/xeninfo/physinfo.go
 create mode 100644 tools/golang/xenlight/test/xeninfo/print.h
 create mode 100644 tools/golang/xenlight/test/xeninfo/versioninfo.c
 create mode 100644 tools/golang/xenlight/test/xeninfo/versioninfo.go
 create mode 12 tools/golang/xenlight/test/xeninfo/xenlight.go

diff --git a/tools/golang/xenlight/test/xeninfo/Makefile 
b/tools/golang/xenlight/test/xeninfo/Makefile
new file mode 100644
index 000..aae5544
--- /dev/null
+++ b/tools/golang/xenlight/test/xeninfo/Makefile
@@ -0,0 +1,41 @@
+XEN_ROOT = $(CURDIR)/../../../../..
+include $(XEN_ROOT)/tools/Rules.mk
+
+GO ?= go
+
+TESTS = dominfo freememory maxcpu onlinecpu physinfo versioninfo
+CBINARIES = $(TESTS:%=%-c)
+GOBINARIES = $(TESTS:%=%-go)
+
+CFLAGS += -Werror
+CFLAGS += $(CFLAGS_libxentoollog)
+CFLAGS += $(CFLAGS_libxenlight)
+
+LDLIBS += $(LDLIBS_libxentoollog)
+LDLIBS += $(LDLIBS_libxenlight)
+
+all: build
+
+test: clean build
+   for test in $(TESTS) ; do \
+   ./$$test-c >> c.output ; \
+   ./$$test-go >> go.output ; \
+   if cmp -s "c.output" "go.output"; then\
+   echo "$$test PASSED";\
+   else \
+   echo "$$test FAILED";\
+   fi ; \
+   done
+
+build: $(CBINARIES) $(GOBINARIES)
+
+%-c: %.c
+   gcc $(CFLAGS) -o $@ $< $(LDLIBS)
+
+%-go: %.go
+   GOPATH=$(XEN_ROOT)/tools/golang $(GO) build -o $@ $<
+
+clean:
+   rm -f *-c
+   rm -f *-go
+   rm -f *.output
diff --git a/tools/golang/xenlight/test/xeninfo/dominfo.c 
b/tools/golang/xenlight/test/xeninfo/dominfo.c
new file mode 100644
index 000..2c63583
--- /dev/null
+++ b/tools/golang/xenlight/test/xeninfo/dominfo.c
@@ -0,0 +1,33 @@
+#include 
+#include 
+#include 
+#include "print.h"
+
+int main(void){
+
+libxl_ctx *context;
+libxl_dominfo info;
+int err;
+long cpu_time;
+context = create_context();
+libxl_dominfo_init();
+err = libxl_domain_info(context, , 0);
+if (err != 0)
+return err;
+
+printf("%d\n%d\n", info.domid, info.ssidref);
+printf("%s\n%s\n%s\n%s\n%s\n%s\n", bool_to_string(info.running), 
+bool_to_string(info.blocked), 

[Xen-devel] [PATCH RFC v3 1/8] golang/xenlight: Create stub package

[Ronald Rojas]

Create a basic Makefile to build and install libxenlight Golang
bindings. Also add a stub package which only opens libxl context.

Include a global xenlight.Ctx variable which can be used as the
default context by the entire program if desired.

For now, return simple errors. Proper error handling will be
added in next patch.

Signed-off-by: Ronald Rojas 
Signed-off-by: George Dunlap 
---

Changes:

- Added global logger variable and destroyed the logger instance
when closing the context.

- Whitespace fixes

CC: xen-devel@lists.xen.org
CC: george.dun...@citrix.com
CC: ian.jack...@eu.citrix.com
CC: wei.l...@citrix.com
---
---
 tools/Makefile|  1 +
 tools/Rules.mk|  7 
 tools/golang/Makefile | 27 
 tools/golang/xenlight/Makefile| 49 ++
 tools/golang/xenlight/xenlight.go | 88 +++
 5 files changed, 172 insertions(+)
 create mode 100644 tools/golang/Makefile
 create mode 100644 tools/golang/xenlight/Makefile
 create mode 100644 tools/golang/xenlight/xenlight.go

diff --git a/tools/Makefile b/tools/Makefile
index 77e0723..caa27f4 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -31,6 +31,7 @@ endif
 
 SUBDIRS-y += xenpmd
 SUBDIRS-y += libxl
+#SUBDIRS-$(CONFIG_GOLANG) += golang
 SUBDIRS-y += helpers
 SUBDIRS-$(CONFIG_X86) += xenpaging
 SUBDIRS-$(CONFIG_X86) += debugger/gdbsx
diff --git a/tools/Rules.mk b/tools/Rules.mk
index b35999b..b5b9ace 100644
--- a/tools/Rules.mk
+++ b/tools/Rules.mk
@@ -30,6 +30,13 @@ XENSTORE_XENSTORED ?= y
 debug ?= y
 debug_symbols ?= $(debug)
 
+# Uncomment to compile with Go
+CONFIG_GOLANG ?= y
+ifeq ($(CONFIG_GOLANG),y)
+XEN_GOPATH= $(XEN_ROOT)/tools/golang
+XEN_GOCODE_URL= golang.xenproject.org
+endif
+
 ifeq ($(debug_symbols),y)
 CFLAGS += -g3
 endif
diff --git a/tools/golang/Makefile b/tools/golang/Makefile
new file mode 100644
index 000..47a9235
--- /dev/null
+++ b/tools/golang/Makefile
@@ -0,0 +1,27 @@
+XEN_ROOT=$(CURDIR)/../..
+include $(XEN_ROOT)/tools/Rules.mk
+
+# In order to link against a package in Go, the package must live in a
+# directory tree in the way that Go expects.  To make this possible,
+# there must be a directory such that we can set GOPATH=${dir}, and
+# the package will be under $GOPATH/src/${full-package-path}.
+
+# So we set XEN_GOPATH to $XEN_ROOT/tools/golang.  The xenlight
+# "package build" directory ($PWD/xenlight) will create the "package
+# source" directory in the proper place.  Go programs can use this
+# package by setting GOPATH=$(XEN_GOPATH).
+
+SUBDIRS-y = xenlight
+
+.PHONY: build all
+all build: subdirs-all
+
+.PHONY: install
+install: subdirs-install
+
+.PHONY: clean
+clean: subdirs-clean
+   $(RM) -r src pkg
+
+.PHONY: distclean
+distclean: clean
diff --git a/tools/golang/xenlight/Makefile b/tools/golang/xenlight/Makefile
new file mode 100644
index 000..5db665d
--- /dev/null
+++ b/tools/golang/xenlight/Makefile
@@ -0,0 +1,49 @@
+XEN_ROOT=$(CURDIR)/../../..
+include $(XEN_ROOT)/tools/Rules.mk
+
+# Standing boldly against convention, we insist on installing the
+# package source under $(prefix)/share/gocode
+GOCODE_DIR ?= $(prefix)/share/gocode/
+GOXL_PKG_DIR = /src/$(XEN_GOCODE_URL)/xenlight/
+GOXL_INSTALL_DIR = $(GOCODE_DIR)$(GOXL_PKG_DIR)
+
+# PKGSOURCES: Files which comprise the distributed source package
+PKGSOURCES = xenlight.go
+
+GO ?= go
+
+.PHONY: all
+all: build
+
+.PHONY: package
+package: $(XEN_GOPATH)$(GOXL_PKG_DIR)$(PKGSOURCES)
+
+$(XEN_GOPATH)/src/$(XEN_GOCODE_URL)/xenlight/$(PKGSOURCES): $(PKGSOURCES)
+   $(INSTALL_DIR) $(XEN_GOPATH)$(GOXL_PKG_DIR)
+   $(INSTALL_DATA) $(PKGSOURCES) $(XEN_GOPATH)$(GOXL_PKG_DIR)
+
+# Go will do its own dependency checking, and not actuall go through
+# with the build if none of the input files have changed.
+#
+# NB that because the users of this library need to be able to
+# recompile the library from source, it needs to include '-lxenlight'
+# in the LDFLAGS; and thus we need to add -L$(XEN_XENLIGHT) here
+# so that it can find the actual library.
+.PHONY: build
+build: package
+   CGO_CFLAGS="$(CFLAGS_libxenlight) $(CFLAGS_libxentoollog)" 
CGO_LDFLAGS="$(LDLIBS_libxenlight) $(LDLIBS_libxentoollog)-L$(XEN_XENLIGHT) 
-L$(XEN_LIBXENTOOLLOG)" GOPATH=$(XEN_GOPATH) $(GO) install -x 
$(XEN_GOCODE_URL)/xenlight
+
+.PHONY: install
+install: build
+   $(INSTALL_DIR) $(DESTDIR)$(GOXL_INSTALL_DIR)
+   $(INSTALL_DATA) $(XEN_GOPATH)$(GOXL_PKG_DIR)$(PKGSOURCES) 
$(DESTDIR)$(GOXL_INSTALL_DIR)
+
+.PHONY: clean
+clean:
+   $(RM) -r $(XEN_GOPATH)$(GOXL_PKG_DIR)
+   $(RM) $(XEN_GOPATH)/pkg/*/$(XEN_GOCODE_URL)/xenlight.a
+
+.PHONY: distclean
+distclean: clean
+
+-include $(DEPS)
diff --git a/tools/golang/xenlight/xenlight.go 
b/tools/golang/xenlight/xenlight.go
new file mode 100644
index 000..b025961
--- /dev/null
+++ b/tools/golang/xenlight/xenlight.go
@@ -0,0 +1,88 @@
+/*
+ * 

[Xen-devel] [PATCH RFC v3 4/8] golang/xenlight: Implement libxl_domain_info and libxl_domain_unpause

[Ronald Rojas]

Add calls for the following host-related functionality:
- libxl_domain_info
- libxl_domain_unpause

Include Golang version for the libxl_domain_info as
DomainInfo.

Signed-off-by: George Dunlap 
Signed-off-by: Ronald Rojas 
---
Changes since last version

- Formating fixes

- used defer for libxl_dominfo_dispose

- Removed unnessary unsafe.Pointer() casts.

CC: xen-devel@lists.xen.org
CC: george.dun...@citrix.com
CC: ian.jack...@eu.citrix.com
CC: wei.l...@citrix.com

---
---
 tools/golang/xenlight/xenlight.go | 136 +-
 1 file changed, 133 insertions(+), 3 deletions(-)

diff --git a/tools/golang/xenlight/xenlight.go 
b/tools/golang/xenlight/xenlight.go
index 785eaaf..34c3050 100644
--- a/tools/golang/xenlight/xenlight.go
+++ b/tools/golang/xenlight/xenlight.go
@@ -33,6 +33,7 @@ import "C"
 
 import (
"fmt"
+   "time"
"unsafe"
 )
 
@@ -102,13 +103,19 @@ var errors = [...]string{
  * Types: Builtins
  */
 
+type Domid uint32
+
+type MemKB uint64
+
+type Uuid C.libxl_uuid
+
 type Context struct {
ctx *C.libxl_ctx
 }
 
 type Hwcap []C.uint32_t
 
-func (chwcap C.libxl_hwcap) CToGo() (ghwcap Hwcap) {
+func (chwcap C.libxl_hwcap) toGo() (ghwcap Hwcap) {
// Alloc a Go slice for the bytes
size := 8
ghwcap = make([]C.uint32_t, size)
@@ -161,7 +168,7 @@ func (cphys *C.libxl_physinfo) toGo() (physinfo *Physinfo) {
physinfo.SharingFreedPages = uint64(cphys.sharing_freed_pages)
physinfo.SharingUsedFrames = uint64(cphys.sharing_used_frames)
physinfo.NrNodes = uint32(cphys.nr_nodes)
-   physinfo.HwCap = cphys.hw_cap.CToGo()
+   physinfo.HwCap = cphys.hw_cap.toGo()
physinfo.CapHvm = bool(cphys.cap_hvm)
physinfo.CapHvmDirectio = bool(cphys.cap_hvm_directio)
 
@@ -203,6 +210,93 @@ func (cinfo *C.libxl_version_info) toGo() (info 
*VersionInfo) {
return
 }
 
+type ShutdownReason int32
+
+const (
+   ShutdownReasonUnknown   = 
ShutdownReason(C.LIBXL_SHUTDOWN_REASON_UNKNOWN)
+   ShutdownReasonPoweroff  = 
ShutdownReason(C.LIBXL_SHUTDOWN_REASON_POWEROFF)
+   ShutdownReasonReboot= ShutdownReason(C.LIBXL_SHUTDOWN_REASON_REBOOT)
+   ShutdownReasonSuspend   = 
ShutdownReason(C.LIBXL_SHUTDOWN_REASON_SUSPEND)
+   ShutdownReasonCrash = ShutdownReason(C.LIBXL_SHUTDOWN_REASON_CRASH)
+   ShutdownReasonWatchdog  = 
ShutdownReason(C.LIBXL_SHUTDOWN_REASON_WATCHDOG)
+   ShutdownReasonSoftReset = 
ShutdownReason(C.LIBXL_SHUTDOWN_REASON_SOFT_RESET)
+)
+
+func (sr ShutdownReason) String() (str string) {
+   cstr := C.libxl_shutdown_reason_to_string(C.libxl_shutdown_reason(sr))
+   str = C.GoString(cstr)
+
+   return
+}
+
+type DomainType int32
+
+const (
+   DomainTypeInvalid = DomainType(C.LIBXL_DOMAIN_TYPE_INVALID)
+   DomainTypeHvm = DomainType(C.LIBXL_DOMAIN_TYPE_HVM)
+   DomainTypePv  = DomainType(C.LIBXL_DOMAIN_TYPE_PV)
+)
+
+func (dt DomainType) String() (str string) {
+   cstr := C.libxl_domain_type_to_string(C.libxl_domain_type(dt))
+   str = C.GoString(cstr)
+
+   return
+}
+
+type Dominfo struct {
+   Uuid  Uuid
+   Domid Domid
+   Ssidref   uint32
+   SsidLabel string
+   Running   bool
+   Blocked   bool
+   Pausedbool
+   Shutdown  bool
+   Dying bool
+   NeverStop bool
+
+   ShutdownReason   int32
+   OutstandingMemkb MemKB
+   CurrentMemkb MemKB
+   SharedMemkb  MemKB
+   PagedMemkb   MemKB
+   MaxMemkb MemKB
+   CpuTime  time.Duration
+   VcpuMaxIduint32
+   VcpuOnline   uint32
+   Cpupool  uint32
+   DomainType   int32
+}
+
+func (cdi *C.libxl_dominfo) toGo() (di *Dominfo) {
+
+   di = {}
+   di.Uuid = Uuid(cdi.uuid)
+   di.Domid = Domid(cdi.domid)
+   di.Ssidref = uint32(cdi.ssidref)
+   di.SsidLabel = C.GoString(cdi.ssid_label)
+   di.Running = bool(cdi.running)
+   di.Blocked = bool(cdi.blocked)
+   di.Paused = bool(cdi.paused)
+   di.Shutdown = bool(cdi.shutdown)
+   di.Dying = bool(cdi.dying)
+   di.NeverStop = bool(cdi.never_stop)
+   di.ShutdownReason = int32(cdi.shutdown_reason)
+   di.OutstandingMemkb = MemKB(cdi.outstanding_memkb)
+   di.CurrentMemkb = MemKB(cdi.current_memkb)
+   di.SharedMemkb = MemKB(cdi.shared_memkb)
+   di.PagedMemkb = MemKB(cdi.paged_memkb)
+   di.MaxMemkb = MemKB(cdi.max_memkb)
+   di.CpuTime = time.Duration(cdi.cpu_time)
+   di.VcpuMaxId = uint32(cdi.vcpu_max_id)
+   di.VcpuOnline = uint32(cdi.vcpu_online)
+   di.Cpupool = uint32(cdi.cpupool)
+   di.DomainType = int32(cdi.domain_type)
+
+   return
+}
+
 /*
  * Context
  */
@@ -332,6 +426,7 @@ func (Ctx *Context) GetPhysinfo() (physinfo *Physinfo, err 
error) {
}
var cphys C.libxl_physinfo
C.libxl_physinfo_init()
+   

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   5 xen-buildfail   never pass
 build-arm64-pvops 5 kernel-build fail   never pass
 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  5d99933e6e3e54da3c7291a0f4bf6c89685b4d24
baseline version:
 xen  bd8451964078b006081fcef6d169961a3a6f746a

Last test of basis   106558  2017-03-08 22:02:27 Z0 days
Testing same since   106569  2017-03-09 17:01:14 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 

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



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=5d99933e6e3e54da3c7291a0f4bf6c89685b4d24
+ . ./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 
5d99933e6e3e54da3c7291a0f4bf6c89685b4d24
+ branch=xen-unstable-smoke
+ revision=5d99933e6e3e54da3c7291a0f4bf6c89685b4d24
+ . ./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.8-testing
+ '[' x5d99933e6e3e54da3c7291a0f4bf6c89685b4d24 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : 

[Xen-devel] [PATCH] xen: don't save/restore the physmap on VM save/restore

[Igor Druzhinin]

Saving/restoring the physmap to/from xenstore was introduced to
QEMU majorly in order to cover up the VRAM region restore issue.
The sequence of restore operations implies that we should know
the effective guest VRAM address *before* we have the VRAM region
restored (which happens later). Unfortunately, in Xen environment
VRAM memory does actually belong to a guest - not QEMU itself -
which means the position of this region is unknown beforehand and
can't be mapped into QEMU address space immediately.

Previously, recreating xenstore keys, holding the physmap, by the
toolstack helped to get this information in place at the right
moment ready to be consumed by QEMU to map the region properly.

The extraneous complexity of having those keys transferred by the
toolstack and unnecessary redundancy prompted us to propose a
solution which doesn't require any extra data in xenstore. The idea
is to defer the VRAM region mapping till the point we actually know
the effective address and able to map it. To that end, we initially
only register the pointer to the framebuffer without actual mapping.
Then, during the memory region restore phase, we perform the mapping
of the known address and update the VRAM region metadata (including
previously registered pointer) accordingly.

Signed-off-by: Igor Druzhinin 
---
 exec.c   |   3 ++
 hw/display/vga.c |   2 +-
 include/hw/xen/xen.h |   2 +-
 xen-hvm.c| 114 ---
 4 files changed, 32 insertions(+), 89 deletions(-)

diff --git a/exec.c b/exec.c
index aabb035..5f2809e 100644
--- a/exec.c
+++ b/exec.c
@@ -2008,6 +2008,9 @@ void *qemu_map_ram_ptr(RAMBlock *ram_block, ram_addr_t 
addr)
 }
 
 block->host = xen_map_cache(block->offset, block->max_length, 1);
+if (block->host == NULL) {
+return NULL;
+}
 }
 return ramblock_ptr(block, addr);
 }
diff --git a/hw/display/vga.c b/hw/display/vga.c
index 69c3e1d..be554c2 100644
--- a/hw/display/vga.c
+++ b/hw/display/vga.c
@@ -2163,7 +2163,7 @@ void vga_common_init(VGACommonState *s, Object *obj, bool 
global_vmstate)
 memory_region_init_ram(>vram, obj, "vga.vram", s->vram_size,
_fatal);
 vmstate_register_ram(>vram, global_vmstate ? NULL : DEVICE(obj));
-xen_register_framebuffer(>vram);
+xen_register_framebuffer(>vram, >vram_ptr);
 s->vram_ptr = memory_region_get_ram_ptr(>vram);
 s->get_bpp = vga_get_bpp;
 s->get_offsets = vga_get_offsets;
diff --git a/include/hw/xen/xen.h b/include/hw/xen/xen.h
index 09c2ce5..3831843 100644
--- a/include/hw/xen/xen.h
+++ b/include/hw/xen/xen.h
@@ -45,6 +45,6 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size,
struct MemoryRegion *mr, Error **errp);
 void xen_modified_memory(ram_addr_t start, ram_addr_t length);
 
-void xen_register_framebuffer(struct MemoryRegion *mr);
+void xen_register_framebuffer(struct MemoryRegion *mr, uint8_t **ptr);
 
 #endif /* QEMU_HW_XEN_H */
diff --git a/xen-hvm.c b/xen-hvm.c
index 5043beb..ea5ed24 100644
--- a/xen-hvm.c
+++ b/xen-hvm.c
@@ -41,6 +41,7 @@
 
 static MemoryRegion ram_memory, ram_640k, ram_lo, ram_hi;
 static MemoryRegion *framebuffer;
+static uint8_t **framebuffer_ptr;
 static bool xen_in_migration;
 
 /* Compatibility with older version */
@@ -302,7 +303,6 @@ static hwaddr xen_phys_offset_to_gaddr(hwaddr start_addr,
 return physmap->start_addr;
 }
 }
-
 return start_addr;
 }
 
@@ -317,7 +317,6 @@ static int xen_add_to_physmap(XenIOState *state,
 XenPhysmap *physmap = NULL;
 hwaddr pfn, start_gpfn;
 hwaddr phys_offset = memory_region_get_ram_addr(mr);
-char path[80], value[17];
 const char *mr_name;
 
 if (get_physmapping(state, start_addr, size)) {
@@ -340,6 +339,27 @@ go_physmap:
 DPRINTF("mapping vram to %"HWADDR_PRIx" - %"HWADDR_PRIx"\n",
 start_addr, start_addr + size);
 
+mr_name = memory_region_name(mr);
+
+physmap = g_malloc(sizeof (XenPhysmap));
+
+physmap->start_addr = start_addr;
+physmap->size = size;
+physmap->name = mr_name;
+physmap->phys_offset = phys_offset;
+
+QLIST_INSERT_HEAD(>physmap, physmap, list);
+
+if (runstate_check(RUN_STATE_INMIGRATE))
+{
+/* At this point we have a physmap entry for the framebuffer region
+ * established during the restore phase so we can safely update the 
+ * registered framebuffer address here. */
+ if (mr == framebuffer)
+*framebuffer_ptr = memory_region_get_ram_ptr(framebuffer);
+return 0;
+}
+
 pfn = phys_offset >> TARGET_PAGE_BITS;
 start_gpfn = start_addr >> TARGET_PAGE_BITS;
 for (i = 0; i < size >> TARGET_PAGE_BITS; i++) {
@@ -350,49 +370,17 @@ go_physmap:
 if (rc) {
 DPRINTF("add_to_physmap MFN %"PRI_xen_pfn" to PFN %"
 PRI_xen_pfn" failed: %d (errno: %d)\n", idx, 

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

[osstest service owner]

flight 106564 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106564/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 105963
 test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 105963

version targeted for testing:
 ovmf e0e1cfcbbb24483f4c3caad3572184fff9b65d24
baseline version:
 ovmf e0307a7dad02aa8c0cd8b3b0b9edce8ddb3fef2e

Last test of basis   105963  2017-02-21 21:43:31 Z   15 days
Failing since105980  2017-02-22 10:03:53 Z   15 days   41 attempts
Testing same since   106564  2017-03-09 08:18:43 Z0 days1 attempts


People who touched revisions under test:
  Anthony PERARD 
  Ard Biesheuvel 
  Bi, Dandan 
  Brijesh Singh 
  Chao Zhang 
  Chen A Chen 
  Dandan Bi 
  edk2-devel On Behalf Of rthomaiy <[mailto:edk2-devel-boun...@lists.01.org]>
  Fu Siyuan 
  Hao Wu 
  Hegde Nagaraj P 
  Hess Chen 
  Jeff Fan 
  Jiaxin Wu 
  Jiewen Yao 
  Laszlo Ersek 
  Leo Duran 
  Paolo Bonzini 
  Qin Long 
  Richard Thomaiyar 
  Ruiyu Ni 
  Star Zeng 
  Wu Jiaxin 
  Yonghong Zhu 
  Zhang Lubo 
  Zhang, Chao B 

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



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

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

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

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


Not pushing.

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

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

Re: [Xen-devel] [PATCH 3/8] xen/9pfs: introduce Xen 9pfs backend

[Greg Kurz]

On Mon,  6 Mar 2017 18:12:43 -0800
Stefano Stabellini  wrote:

> Introduce the Xen 9pfs backend: add struct XenDevOps to register as a
> Xen backend and add struct V9fsTransport to register as v9fs transport.
> 
> All functions are empty stubs for now.
> 
> Signed-off-by: Stefano Stabellini 
> CC: anthony.per...@citrix.com
> CC: jgr...@suse.com
> CC: Aneesh Kumar K.V 
> CC: Greg Kurz 
> ---
>  hw/9pfs/xen-9p-backend.c | 96 
> 
>  1 file changed, 96 insertions(+)
>  create mode 100644 hw/9pfs/xen-9p-backend.c
> 
> diff --git a/hw/9pfs/xen-9p-backend.c b/hw/9pfs/xen-9p-backend.c
> new file mode 100644
> index 000..924fb64
> --- /dev/null
> +++ b/hw/9pfs/xen-9p-backend.c
> @@ -0,0 +1,96 @@
> +/*
> + * Xen 9p backend
> + *
> + * Copyright Aporeto 2017
> + *
> + * Authors:
> + *  Stefano Stabellini 
> + *
> + */
> +
> +#include "qemu/osdep.h"
> +
> +#include "hw/hw.h"
> +#include "hw/9pfs/9p.h"
> +#include "hw/xen/xen_backend.h"
> +#include "xen_9pfs.h"
> +#include "qemu/config-file.h"
> +#include "fsdev/qemu-fsdev.h"
> +
> +struct Xen9pfsDev {
> +struct XenDevice xendev;  /* must be first */
> +};

According to HACKING, this should be:

typedef struct Xen9pfsDev {
struct XenDevice xendev;  /* must be first */
} Xen9pfsDev;

and...

> +
> +static ssize_t xen_9pfs_pdu_vmarshal(V9fsPDU *pdu,
> + size_t offset,
> + const char *fmt,
> + va_list ap)
> +{
> +return 0;
> +}
> +
> +static ssize_t xen_9pfs_pdu_vunmarshal(V9fsPDU *pdu,
> +   size_t offset,
> +   const char *fmt,
> +   va_list ap)
> +{
> +return 0;
> +}
> +
> +static void xen_9pfs_init_out_iov_from_pdu(V9fsPDU *pdu,
> +   struct iovec **piov,
> +   unsigned int *pniov)
> +{
> +}
> +
> +static void xen_9pfs_init_in_iov_from_pdu(V9fsPDU *pdu,
> +  struct iovec **piov,
> +  unsigned int *pniov,
> +  size_t size)
> +{
> +}
> +
> +static void xen_9pfs_push_and_notify(V9fsPDU *pdu)
> +{
> +}
> +
> +static const struct V9fsTransport xen_9p_transport = {
> +.pdu_vmarshal = xen_9pfs_pdu_vmarshal,
> +.pdu_vunmarshal = xen_9pfs_pdu_vunmarshal,
> +.init_in_iov_from_pdu = xen_9pfs_init_in_iov_from_pdu,
> +.init_out_iov_from_pdu = xen_9pfs_init_out_iov_from_pdu,
> +.push_and_notify = xen_9pfs_push_and_notify,
> +};
> +
> +static int xen_9pfs_init(struct XenDevice *xendev)
> +{
> +return 0;
> +}
> +
> +static int xen_9pfs_free(struct XenDevice *xendev)
> +{
> +return -1;
> +}
> +
> +static int xen_9pfs_connect(struct XenDevice *xendev)
> +{
> +return 0;
> +}
> +
> +static void xen_9pfs_alloc(struct XenDevice *xendev)
> +{
> +}
> +
> +static void xen_9pfs_disconnect(struct XenDevice *xendev)
> +{
> +}
> +
> +struct XenDevOps xen_9pfs_ops = {
> +.size   = sizeof(struct Xen9pfsDev),

... s/struct //

> +.flags  = DEVOPS_FLAG_NEED_GNTDEV,
> +.alloc  = xen_9pfs_alloc,
> +.init   = xen_9pfs_init,
> +.initialise= xen_9pfs_connect,
> +.disconnect = xen_9pfs_disconnect,
> +.free   = xen_9pfs_free,
> +};

With the above comments addressed:

Reviewed-by: Greg Kurz 


pgpfxdKMuqYCL.pgp
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [Qemu-devel] [PATCH 8/8] xen/9pfs: build and register Xen 9pfs backend

[Greg Kurz]

On Mon,  6 Mar 2017 18:12:48 -0800
Stefano Stabellini  wrote:

> Signed-off-by: Stefano Stabellini 
> CC: anthony.per...@citrix.com
> CC: jgr...@suse.com
> CC: Aneesh Kumar K.V 
> CC: Greg Kurz 
> ---
>  hw/9pfs/Makefile.objs| 1 +
>  hw/xen/xen_backend.c | 1 +
>  include/hw/xen/xen_backend.h | 1 +
>  3 files changed, 3 insertions(+)
> 
> diff --git a/hw/9pfs/Makefile.objs b/hw/9pfs/Makefile.objs
> index da0ae0c..76a81c3 100644
> --- a/hw/9pfs/Makefile.objs
> +++ b/hw/9pfs/Makefile.objs
> @@ -7,3 +7,4 @@ common-obj-$(CONFIG_OPEN_BY_HANDLE) +=  9p-handle.o
>  common-obj-y += 9p-proxy.o
>  
>  obj-y += virtio-9p-device.o
> +obj-y += xen-9p-backend.o

The xen-9p-backend.c file seems to be target agnostic: it can be built
only once. Also, it should only be built if QEMU was configured with
Xen support. Hence:

obj-common-$(CONFIG_XEN_BACKEND) += xen-9p-backend.o

> diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
> index 6c21c37..7aa347d 100644
> --- a/hw/xen/xen_backend.c
> +++ b/hw/xen/xen_backend.c
> @@ -585,6 +585,7 @@ void xen_be_register_common(void)
>  xen_be_register("console", _console_ops);
>  xen_be_register("vkbd", _kbdmouse_ops);
>  xen_be_register("qdisk", _blkdev_ops);

#ifdef CONFIG_VIRTFS

> +xen_be_register("9pfs", _9pfs_ops);

#endif

>  #ifdef CONFIG_USB_LIBUSB
>  xen_be_register("qusb", _usb_ops);
>  #endif
> diff --git a/include/hw/xen/xen_backend.h b/include/hw/xen/xen_backend.h
> index 4f4799a..84e686c 100644
> --- a/include/hw/xen/xen_backend.h
> +++ b/include/hw/xen/xen_backend.h
> @@ -49,6 +49,7 @@ extern struct XenDevOps xen_console_ops;  /* 
> xen_console.c */
>  extern struct XenDevOps xen_kbdmouse_ops; /* xen_framebuffer.c */
>  extern struct XenDevOps xen_framebuffer_ops;  /* xen_framebuffer.c */
>  extern struct XenDevOps xen_blkdev_ops;   /* xen_disk.c*/
> +extern struct XenDevOps xen_9pfs_ops;   /* xen-9p-backend.c*/

ditto

>  extern struct XenDevOps xen_netdev_ops;   /* xen_nic.c */
>  #ifdef CONFIG_USB_LIBUSB
>  extern struct XenDevOps xen_usb_ops;  /* xen-usb.c */

With the above fixes.

Reviewed-by: Greg Kurz 


pgpBV7GTArJTB.pgp
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-pvops 3 host-install(3) broken REGR. vs. 59254
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail REGR. vs. 59254
 test-amd64-i386-xl-qemuu-winxpsp3 17 guest-start/win.repeat fail REGR. vs. 
59254

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds  9 debian-installfail REGR. vs. 59254
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 59254
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 59254
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 59254
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 59254

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-xsm   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 build-arm64-xsm   5 xen-buildfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 build-arm64   5 xen-buildfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass

version targeted for testing:
 linuxea6200e84182989a3cce9687cf79a23ac44ec4db
baseline version:
 linux45820c294fe1b1a9df495d57f40585ef2d069a39

Last test of basis59254  2015-07-09 04:20:48 Z  609 days
Failing since 59348  2015-07-10 04:24:05 Z  608 days  322 attempts
Testing same since   106563  2017-03-09 07:17:51 Z0 days1 attempts


8049 people touched revisions under test,
not listing them all

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  fail
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  fail
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-arm64-libvirt  blocked 
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-arm64-pvopspass
 build-armhf-pvopsbroken  
 build-i386-pvops  

Re: [Xen-devel] [PATCH V2] x86/altp2m: Added xc_altp2m_set_mem_access_multi()

[Tamas K Lengyel]

On Thu, Mar 9, 2017 at 9:56 AM, Jan Beulich  wrote:
 On 09.03.17 at 10:38,  wrote:
>> @@ -4535,6 +4536,30 @@ static int do_altp2m_op(
>>  a.u.set_mem_access.view);
>>  break;
>>
>> +case HVMOP_altp2m_set_mem_access_multi:
>> +if ( a.u.set_mem_access_multi.pad ||
>> + a.u.set_mem_access_multi.opaque >= a.u.set_mem_access_multi.nr 
>> )
>> +{
>> +rc = -EINVAL;
>> +break;
>> +}
>> +rc = p2m_set_mem_access_multi(d, a.u.set_mem_access_multi.pfn_list,
>> +  a.u.set_mem_access_multi.access_list,
>> +  a.u.set_mem_access_multi.nr,
>> +  a.u.set_mem_access_multi.opaque,
>> +  MEMOP_CMD_MASK,
>> +  a.u.set_mem_access_multi.view);
>> +if ( rc > 0 )
>> +{
>> +a.u.set_mem_access_multi.opaque = rc;
>> +if ( __copy_to_guest(arg, , 1) )
>> +rc = -EFAULT;
>> +else
>> +rc = hypercall_create_continuation(__HYPERVISOR_hvm_op, 
>> "lh",
>> +   HVMOP_altp2m, arg);
>> +}
>> +break;
>
> Okay, so this is a hvmop, in which case I'm fine with the continuation
> model used.
>
> However - is this interface supposed to be usable by a guest on itself?
> Arguably the same question would apply to some of the other sub-ops
> too, but anyway.
>

AFAIK the only op the guest would use on itself is
HVMOP_altp2m_vcpu_enable_notify.

Tamas

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

Re: [Xen-devel] [PATCH V2] x86/altp2m: Added xc_altp2m_set_mem_access_multi()

[Razvan Cojocaru]

On 03/09/2017 06:56 PM, Jan Beulich wrote:
 On 09.03.17 at 10:38,  wrote:
>> @@ -4535,6 +4536,30 @@ static int do_altp2m_op(
>>  a.u.set_mem_access.view);
>>  break;
>>  
>> +case HVMOP_altp2m_set_mem_access_multi:
>> +if ( a.u.set_mem_access_multi.pad ||
>> + a.u.set_mem_access_multi.opaque >= a.u.set_mem_access_multi.nr 
>> )
>> +{
>> +rc = -EINVAL;
>> +break;
>> +}
>> +rc = p2m_set_mem_access_multi(d, a.u.set_mem_access_multi.pfn_list,
>> +  a.u.set_mem_access_multi.access_list,
>> +  a.u.set_mem_access_multi.nr,
>> +  a.u.set_mem_access_multi.opaque,
>> +  MEMOP_CMD_MASK,
>> +  a.u.set_mem_access_multi.view);
>> +if ( rc > 0 )
>> +{
>> +a.u.set_mem_access_multi.opaque = rc;
>> +if ( __copy_to_guest(arg, , 1) )
>> +rc = -EFAULT;
>> +else
>> +rc = hypercall_create_continuation(__HYPERVISOR_hvm_op, 
>> "lh",
>> +   HVMOP_altp2m, arg);
>> +}
>> +break;
> 
> Okay, so this is a hvmop, in which case I'm fine with the continuation
> model used.
> 
> However - is this interface supposed to be usable by a guest on itself?
> Arguably the same question would apply to some of the other sub-op
> too, but anyway.

Not for any of our use cases. The whole point is for dom0 (or another
suitably privileged domain) to monitor another guest that consequently
can't, by design, evade detection of bad behaviour by acting at a higher
privilege level than the protection software. It wouldn't make sense for
a domain to be doing this on itself.

Maybe Tamas has something in mind, but the short answer is no, it's not.

>> --- a/xen/include/public/hvm/hvm_op.h
>> +++ b/xen/include/public/hvm/hvm_op.ht
>> @@ -231,6 +231,23 @@ struct xen_hvm_altp2m_set_mem_access {
>>  typedef struct xen_hvm_altp2m_set_mem_access 
>> xen_hvm_altp2m_set_mem_access_t;
>>  DEFINE_XEN_GUEST_HANDLE(xen_hvm_altp2m_set_mem_access_t);
>>  
>> +struct xen_hvm_altp2m_set_mem_access_multi {
>> +/* view */
>> +uint16_t view;
>> +uint16_t pad;
>> +/* Number of pages */
>> +uint32_t nr;
>> +/* Used for continuation purposes */
>> +uint64_t opaque;
>> +/* List of pfns to set access for */
>> +XEN_GUEST_HANDLE(const_uint64) pfn_list;
>> +/* Corresponding list of access settings for pfn_list */
>> +XEN_GUEST_HANDLE(const_uint8) access_list;
> 
> I'm afraid these handles aren't going to work for a 32-bit guest. Note
> how no other hvmop uses handles.

Right, I guess I'll have to pass these through the compat code then,
like the xc_set_mem_access_multi() code does. I'll take a look at what
that entails.


Thanks,
Razvan

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

Re: [Xen-devel] [PATCH v5 0/3] Significant changes to Xen Project Governance (governance.html) - COMMITTERS PLEASE VOTE ON THE PROPOSAL

[Lars Kurth]

Hi all,

that is now live at https://xenproject.org/governance.html and committed (with 
manually beautified html to make tables look good) at 
http://xenbits.xen.org/gitweb/?p=people/larsk/governance.git;a=summary

At some point probably a blog post is in order, but am too busy right now

Regards
Lars 

> On 22 Feb 2017, at 12:00, Lars Kurth  wrote:
> 
> 
>> On 23 Nov 2016, at 12:20, Lars Kurth  wrote:
>> 
>> THIS IS VERSION 5 OF THIS PATCH AND WE ARE READY FOR FORMAL VOTING, UNLESS
>> SOMEONE OBJECTS. PEOPLE LISTED AS COMMITTERS IN
>> - https://xenproject.org/developers/teams/hypervisor.html
>> - https://xenproject.org/developers/teams/xapi.html
>> PLEASE VOTE BEFORE DEC 2nd
> 
> I wanted to summarise the voting on this proposal so far
> 
> v3:
> https://lists.xenproject.org/archives/html/xen-devel/2016-08/threads.html#01667
> 
> In favour
> Jan Beulich
> Tim Deegan (agreed on the basis of a fix which was addressed in v5)
> Wei Liu
> 
> v4:
> Not posted. Only fixed formatting issues
> 
> v5:
> https://lists.xenproject.org/archives/html/xen-devel/2016-11/threads.html#01917
> 
> In favour
> Konrad R Wilk
> Ian Jackson (although was not very explicit)
> Stefano Stabellini (see 
> https://lists.xenproject.org/archives/html/xen-devel/2017-02/msg01845.html) 
> 
> It does appear to me that the proposal should pass given the votes. I will 
> publish the new version
> on Friday or early next week, if I don't get any other opinions. I will also 
> prepare a blog post
> with Zibby's help for some point afterwards.
> 
> Best Regards
> Lars
> 
> 
>> I made some significant proposed changes to governance.html based on a 
>> number 
>> of issues that were raised in a number of surveys last year, and via other 
>> means, as well as in the recent discussions related to governance.html 
>> changes 
>> (the issue of too many committers in XAPI and XAPI being able to hijack the 
>> entire project).
>> 
>> In any case, the changes are expressed in 3 patches governance.pandoc,
>> which is the pandoc source for governance.html:
>> 
>> - Code motion changes to make real patches easier to read
>> No content has been changed
>> An index was added
>> Fixed some minor typos and formatting issues
>> 
>> - Added document containing governance related todo list
>> These do not affect this series and are basically a TODO list for myself
>> 
>> - Significant changes to decision making; some new roles; minor changes
>> Added Goal: Local Decision Making
>> Split roles into project wide and sub-project specific roles
>> Added new roles: Community Manager, Security Response Team, Leadership Team
>> Added RTC Policy
>> Added +2 ... -2 scheme for expressing opinions more clearly
>> Clarified lazy consensus / lazy voting with examples
>> Added Informal Votes or Surveys
>> Added Project Team Leadership decisions (majority vote, non-monotonicity)
>> Clarified and Adapted Conflict Resolution to previous changes
>> Updated Elections to cover new roles and terminology
>> Changed Project Wide Decision making (per project, non-monotonicity)
>> Clarified scope of Decision making
>> Added section on Community Decisions with Funding and Legal Implications
>> Modified all other sections which have dependencies on changes above
>> Added Per Sub-Project Governance Specialisation
>> Fixed some typos
>> 
>> The patch series is based on 
>> git://xenbits.xen.org/people/larsk/governance.git
>> 
>> You can see the changes in my personal git repo at 
>> http://xenbits.xen.org/gitweb/
>> ?p=people/larsk/governance.git;a=shortlog;h=refs/heads/2016-overhaul-v5
>> 
>> Open Issues to be fixed (but these don't need to be reviewed)
>> - Fix up tables as these don't render very nicely as html
>> Also see http://rapporter.github.io/pander/pandoc_table.html
>> 
>> ---
>> Changes since v1
>> - Agreed and changed counting schemes for lazy consensus/votinh
>> - Added Community Decisions with Funding and Legal Implications
>> - Clarified AB role in last resort cases
>> - Removed comments where superceded by decisions we already made
>> - Adapted sections with dependencies
>> 
>> Changes since v2
>> - Fixed minor typographic issues
>> - Removed comments from the series, as these are distracting
>> and make the document harder to review
>> - Broke out remaining comments that need addressing at some
>> point into governance.todo
>> - Added an extra patch regarding quorum and security team
>> members
>> 
>> Changes since v3
>> - Fixed quorum for global decision making
>> 
>> Changes since v4 (not posted)
>> - Fixed conversion issues and changelog in document
>> 
>> -- 
>> 2.5.4 (Apple Git-61)
>> 
>> 
>> ___
>> win-pv-devel mailing list
>> win-pv-de...@lists.xenproject.org
>> https://lists.xenproject.org/cgi-bin/mailman/listinfo/win-pv-devel
> 


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

Re: [Xen-devel] [PATCH V2] x86/altp2m: Added xc_altp2m_set_mem_access_multi()

[Jan Beulich]

>>> On 09.03.17 at 10:38,  wrote:
> @@ -4535,6 +4536,30 @@ static int do_altp2m_op(
>  a.u.set_mem_access.view);
>  break;
>  
> +case HVMOP_altp2m_set_mem_access_multi:
> +if ( a.u.set_mem_access_multi.pad ||
> + a.u.set_mem_access_multi.opaque >= a.u.set_mem_access_multi.nr )
> +{
> +rc = -EINVAL;
> +break;
> +}
> +rc = p2m_set_mem_access_multi(d, a.u.set_mem_access_multi.pfn_list,
> +  a.u.set_mem_access_multi.access_list,
> +  a.u.set_mem_access_multi.nr,
> +  a.u.set_mem_access_multi.opaque,
> +  MEMOP_CMD_MASK,
> +  a.u.set_mem_access_multi.view);
> +if ( rc > 0 )
> +{
> +a.u.set_mem_access_multi.opaque = rc;
> +if ( __copy_to_guest(arg, , 1) )
> +rc = -EFAULT;
> +else
> +rc = hypercall_create_continuation(__HYPERVISOR_hvm_op, "lh",
> +   HVMOP_altp2m, arg);
> +}
> +break;

Okay, so this is a hvmop, in which case I'm fine with the continuation
model used.

However - is this interface supposed to be usable by a guest on itself?
Arguably the same question would apply to some of the other sub-ops
too, but anyway.

> --- a/xen/include/public/hvm/hvm_op.h
> +++ b/xen/include/public/hvm/hvm_op.h
> @@ -231,6 +231,23 @@ struct xen_hvm_altp2m_set_mem_access {
>  typedef struct xen_hvm_altp2m_set_mem_access xen_hvm_altp2m_set_mem_access_t;
>  DEFINE_XEN_GUEST_HANDLE(xen_hvm_altp2m_set_mem_access_t);
>  
> +struct xen_hvm_altp2m_set_mem_access_multi {
> +/* view */
> +uint16_t view;
> +uint16_t pad;
> +/* Number of pages */
> +uint32_t nr;
> +/* Used for continuation purposes */
> +uint64_t opaque;
> +/* List of pfns to set access for */
> +XEN_GUEST_HANDLE(const_uint64) pfn_list;
> +/* Corresponding list of access settings for pfn_list */
> +XEN_GUEST_HANDLE(const_uint8) access_list;

I'm afraid these handles aren't going to work for a 32-bit guest. Note
how no other hvmop uses handles.

Jan


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

[Xen-devel] [raisin] Using cirros for tests???

[Gémes Géza]

Hi,

I've sent my last couple of days on trying to make raisin tests run on 
different distributions. Tried Ubuntu 16.04, Ubuntu 14.04, CentOS 7 and 
CentOS 6.8 so far. The tests fail because of different reasons on these 
distributions:


1. bussybox-pv passes on Ubuntu 14.04 and 16.04, it fails on Centos 7 
(there is no bussybox in the default repositories, enabling EPEL might 
be too intrusive), it also fails on Centos6 (I haven't track that down yet)


2. bussybox-hvm fails on all the tried distros. On Ubuntu and CentOS 7 
(all of them have grub 2.0.2) grub fails to find the filesystem with 
stage2 and at boot stops at grub-rescue> with no partitions recognized. 
In addition on Ubuntu 16.04 the lopartsetup script fails to set up the 
partition correctly, which could be quite easily get fixed.


My idea is that instead of trying to fix the tests (and to continue to 
do so for upcoming distro releases) we could start using cirros images 
for the tests.


I'd start transforming the existing tests to use cirros if you agree 
with the proposal.


Cheers,

Geza



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

Re: [Xen-devel] [PATCH v2 6/7] xen/9pfs: receive responses

[Boris Ostrovsky]

On 03/08/2017 06:58 PM, Stefano Stabellini wrote:
> Upon receiving a notification from the backend, schedule the
> p9_xen_response work_struct. p9_xen_response checks if any responses are
> available, if so, it reads them one by one, calling p9_client_cb to send
> them up to the 9p layer (p9_client_cb completes the request). Handle the
> ring following the Xen 9pfs specification.
>
> Signed-off-by: Stefano Stabellini 
> CC: boris.ostrov...@oracle.com
> CC: jgr...@suse.com
> CC: Eric Van Hensbergen 
> CC: Ron Minnich 
> CC: Latchesar Ionkov 
> CC: v9fs-develo...@lists.sourceforge.net

Reviewed-by: Boris Ostrovsky 


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

Re: [Xen-devel] [PATCH 2/4] misc/release-checklist: Remove pre-4.3 tarball target instructions

[Jan Beulich]

>>> On 09.03.17 at 16:53,  wrote:
> Jan Beulich writes ("Re: [PATCH 2/4] misc/release-checklist: Remove pre-4.3 
> tarball target instructions"):
>> On 09.03.17 at 16:19,  wrote:
>> > @@ -232,14 +202,10 @@ GZIP=-9v tar zcf 
>> > /volatile/iwj/website-thing/xen.org/oss-xen/release/$v/xen-$v.t
>> > -(make -j4 KERNELS='' && echo ok.) 2>&1 | tee ../log.$v
>> >   # pre 4.2
>> >  (./configure && make -j4 KERNELS='' && echo ok.) 2>&1 | 
>> > tee ../log.$v   # post 4.2
>> 
>> Wouldn't this then better get the comment at the end of the line
>> dropped too?
> 
> Maybe.  It doesn't hurt cut-and-paste, and means that if anyone tries
> this with 4.1.x for some absurd reason, they don't trip over it.

Okay, keep it then.

Jan


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

Re: [Xen-devel] [PATCH 3/4] misc/release-checklist: Split out branching-checklist.txt

[Ian Jackson]

Jan Beulich writes ("Re: [PATCH 3/4] misc/release-checklist: Split out 
branching-checklist.txt"):
> On 09.03.17 at 16:19,  wrote:
> > +##* tag branchpoint
> > +##hg tag $v.0-branched
> > +##hg sign -k 'Xen tree' 4.1.0-branched
> 
> Does this Mercurial stuff need keeping?

No.  But, I think I would prefer to clean this out when I (or someone
else) next goes through this checklist, rather than proactively.  This
kind of thing is really easy to get right when you're actually doing
it.

Ian.

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

Re: [Xen-devel] [PATCH 2/4] misc/release-checklist: Remove pre-4.3 tarball target instructions

[Ian Jackson]

Jan Beulich writes ("Re: [PATCH 2/4] misc/release-checklist: Remove pre-4.3 
tarball target instructions"):
> On 09.03.17 at 16:19,  wrote:
> > @@ -232,14 +202,10 @@ GZIP=-9v tar zcf 
> > /volatile/iwj/website-thing/xen.org/oss-xen/release/$v/xen-$v.t
> > -(make -j4 KERNELS='' && echo ok.) 2>&1 | tee ../log.$v 
> >  # pre 4.2
> >  (./configure && make -j4 KERNELS='' && echo ok.) 2>&1 | 
> > tee ../log.$v   # post 4.2
> 
> Wouldn't this then better get the comment at the end of the line
> dropped too?

Maybe.  It doesn't hurt cut-and-paste, and means that if anyone tries
this with 4.1.x for some absurd reason, they don't trip over it.
If you want to remove it I don't object.

I'd rather not let the perfect be the enemy of the tolerable, here.

Ian.

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

Re: [Xen-devel] [PATCH 0/4] misc/release-checklist: Updates prompted by recent release

[Jan Beulich]

>>> On 09.03.17 at 16:19,  wrote:
> When doing the recent stable release branches, I tripped over some
> deficiencies in these checklists.  And, now that they are in git, we
> can much more safely throw away a lot of ancient stuff.
> 
> Please shout if you have any objections.  I hope to push this today.

No objections; I've just sent a few minor comments.

Jan


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

Re: [Xen-devel] [PATCH 3/4] misc/release-checklist: Split out branching-checklist.txt

[Jan Beulich]

>>> On 09.03.17 at 16:19,  wrote:
> --- /dev/null
> +++ b/misc/branching-checklist.txt
> @@ -0,0 +1,97 @@
> +v=4.1
> +ov=4.0
> +
> +##* tag branchpoint
> +##hg tag $v.0-branched
> +##hg sign -k 'Xen tree' 4.1.0-branched

Does this Mercurial stuff need keeping?

> +* make branch in qemu-iwj.git
> +git-branch $v-testing master
> +
> +# make branches in xenbits.xen.org qemus
> +ssh x...@xenbits.xen.org 
> + cd ~/git/qemu-xen.git
> + git branch staging-$v staging
> + git branch stable-$v master
> + cd ~/git/qemu-xen-traditional.git
> + git branch stable-$v master
> +
> +# make branch in libvirt
> +ssh x...@xenbits.xen.org 
> +cd ~/git/libvirt.git/
> + git branch osstest/frozen/xen-$v-testing   xen-tested-master
> +
> +# make branches in xenbits.xen.org xen.git
> +ssh x...@xenbits.xen.org 
> +cd ~/git/xen.git
> + git branch staging-$v staging
> + git branch stable-$v master
> +
> +# update xendocs@xenbits docs generator to generate new stable branch
> +#  docs too. commit to git.
> +* make 13:37  http://xenbits.xen.org/docs/4.2-testing/ is now live true
> +#14:17  HOWTO: login to xenbits. become "xendocs" . cd cronjobs . edit
> +#xenbits-docs-all.sh in the obvious way. git commit
> + ssh r...@xenbits.xen.org 
> + su - xendocs
> + cd cronjobs
> + ed xenbits-docs-all.sh
> + /for branch
> + s/$/ 4.6-testing
> + # ^ OR SIMILAR
> + w
> + q
> +git add -p
> + git commit -m "Branch for $v"
> +
> +### * make symlink on mariner for qemu
> +###cd /var/www/git/
> +###ln -s /usr/groups/xencore/HG/qemu-xen-$v-testing.git .

This also looks to be Mercurial related.

Jan


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

Re: [Xen-devel] [PATCH 2/4] misc/release-checklist: Remove pre-4.3 tarball target instructions

[Jan Beulich]

>>> On 09.03.17 at 16:19,  wrote:
> @@ -232,14 +202,10 @@ GZIP=-9v tar zcf 
> /volatile/iwj/website-thing/xen.org/oss-xen/release/$v/xen-$v.t
>  #rsync -a --delete xen-$v build/
>  cd xen-$v
>  export http_proxy=http://localhost:3128/ 
> -(make -j4 KERNELS='' && echo ok.) 2>&1 | tee ../log.$v   
># pre 4.2
>  (./configure && make -j4 KERNELS='' && echo ok.) 2>&1 | tee 
> ../log.$v   # post 4.2

Wouldn't this then better get the comment at the end of the line
dropped too?

Jan


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

Re: [Xen-devel] [PATCH v2 5/7] xen/9pfs: send requests to the backend

[Boris Ostrovsky]

On 03/08/2017 06:58 PM, Stefano Stabellini wrote:
> Implement struct p9_trans_module create and close functions by looking
> at the available Xen 9pfs frontend-backend connections. We don't expect
> many frontend-backend connections, thus walking a list is OK.
>
> Send requests to the backend by copying each request to one of the
> available rings (each frontend-backend connection comes with multiple
> rings). Handle the ring and notifications following the 9pfs
> specification. If there are not enough free bytes on the ring for the
> request, wait on the wait_queue: the backend will send a notification
> after consuming more requests.
>
> Signed-off-by: Stefano Stabellini 
> CC: boris.ostrov...@oracle.com
> CC: jgr...@suse.com
> CC: Eric Van Hensbergen 
> CC: Ron Minnich 
> CC: Latchesar Ionkov 
> CC: v9fs-develo...@lists.sourceforge.net
> ---

Reviewed-by: Boris Ostrovsky 


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

Re: [Xen-devel] [PATCH v16 4/9] x86: add multiboot2 protocol support for EFI platforms

[Jan Beulich]

>>> On 09.03.17 at 16:24,  wrote:
> Though it looks that I found a bug in Xen IOMMU code. If I run Xen from master
> in QEMU then QEMU complains and crashes:
> 
>   qemu-system-x86_64: /srv/dev/qemu/qemu_20170308/hw/i386/intel_iommu.c:1786: 
> vtd_mem_write: Assertion `size == 4' failed.
>   Aborted (core dumped)
> 
> So, I took a look at dma_msi_set_affinity() and found this:
> 
>   dmar_writeq(iommu->reg, DMAR_FEADDR_REG, msg.address);
> 
> It looks bogus because DMAR_FEADDR_REG is defined in spec as 32-bit wide.
> So, applied this patch:
> 
> -dmar_writeq(iommu->reg, DMAR_FEADDR_REG, msg.address);
> +dmar_writel(iommu->reg, DMAR_FEADDR_REG, msg.address_lo);
> +if (x2apic_enabled)
> +dmar_writel(iommu->reg, DMAR_FEUADDR_REG, msg.address_hi);
> 
> Ant it looks that right now everything works.
> 
> If patch make sense I can post it with proper commit message.

Please see commit ae05fd3912 ("VT-d: use qword MMIO access for
MSI address writes") before you consider posting a patch.

Jan


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

Re: [Xen-devel] [PATCH v16 4/9] x86: add multiboot2 protocol support for EFI platforms

[Andrew Cooper]

On 09/03/17 15:24, Daniel Kiper wrote:
> On Tue, Mar 07, 2017 at 12:39:04AM +0100, Daniel Kiper wrote:
>> On Wed, Feb 22, 2017 at 09:04:17AM -0800, Doug Goldstein wrote:
>>
>> [...]
>>
>>> I'm currently at ELC and then on vacation so I don't have access to any
>>> of the machines currently myself. However the machine I most use to test
>>> is a NUC5i5MYHE and a NUC5i3MYHE if you want to ask around if someone
>>> has one internally. But that's why I gave QEMU as an example.
>>>
>>> I was using qemu master from a few weeks ago. I'll have to find the
>>> revision for you. But the command line I use is:
>>>
>>> -enable-kvm -M pc-q35-2.8 -device intel-iommu -cpu host -m 2048 -smp 2
>>> -drive if=pflash,format=raw,file=/tmp/tmp.EiR6ixmYzV -global
>>> isa-debugcon.iobase=0x402 -debugcon file:/tmp/tmp.nuvEXUWfnA -monitor
>>> stdio -chardev socket,host=127.0.0.1,port=25914,id=S0,server,nowait
>>> -device isa-serial,chardev=S0 -device piix3-usb-uhci -device usb-tablet
>>> -netdev id=net0,type=tap -device
>>> virtio-net-pci,netdev=net0,mac=52:54:00:12:34:56 -boot order=n -device
>>> qxl-vga -gdb tcp::14952
>> Sadly, my colleagues and I are not able to reproduce the problem on any of
>> machines available for us (available on the market and some development
>> stuff in our labs). I did tests with QEMU (I am not able to run it with
>> "-device intel-iommu" on my machine; I have to investigate this). Everything
>> works. Joao did some tests on Intel NUC D34010WYK second generation.
>> Everything works. So, Konrad ordered Intel NUC NUC5i3MYHE for me. I am
>> waiting for delivery. Doug, could you tell me what distro, Xen, etc. you
>> have installed on that NUC? I would like to test same config as yours on
>> this machine.
> Latest QEMU from git with intel-iommu device enabled works without any issue.
> Though it looks that I found a bug in Xen IOMMU code. If I run Xen from master
> in QEMU then QEMU complains and crashes:
>
>   qemu-system-x86_64: /srv/dev/qemu/qemu_20170308/hw/i386/intel_iommu.c:1786: 
> vtd_mem_write: Assertion `size == 4' failed.
>   Aborted (core dumped)
>
> So, I took a look at dma_msi_set_affinity() and found this:
>
>   dmar_writeq(iommu->reg, DMAR_FEADDR_REG, msg.address);
>
> It looks bogus because DMAR_FEADDR_REG is defined in spec as 32-bit wide.
> So, applied this patch:
>
> -dmar_writeq(iommu->reg, DMAR_FEADDR_REG, msg.address);
> +dmar_writel(iommu->reg, DMAR_FEADDR_REG, msg.address_lo);
> +if (x2apic_enabled)
> +dmar_writel(iommu->reg, DMAR_FEUADDR_REG, msg.address_hi);

EFI aside, that is clearly a qemu bug (as Xen shouldn't be able to cause
an assertion like that to be hit), and there is nothing wrong with Xens
code as-is.

All the spec requires is that 32bit fields are accessed as whole
doublewords (rather than smaller units).  There is no restriction on
updating two adjacent 32bit fields with a quadword access. 
(Furthermore, hardware is requires to cope with accesses to a 64bit
field being decomposed into two 32bit accesses.)

~Andrew

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

Re: [Xen-devel] [PATCH v2 4/7] xen/9pfs: connect to the backend

[Boris Ostrovsky]

> +
> +static int xen_9pfs_front_alloc_dataring(struct xenbus_device *dev,
> + struct xen_9pfs_dataring *ring)
> +{
> + int i;
> + int ret = -ENOMEM;
> +
> + init_waitqueue_head(>wq);
> + spin_lock_init(>lock);
> + INIT_WORK(>work, p9_xen_response);
> +
> + ring->intf = (struct xen_9pfs_data_intf *) get_zeroed_page(GFP_KERNEL | 
> __GFP_ZERO);
> + if (!ring->intf)
> + return ret;
> + ring->ref = gnttab_grant_foreign_access(dev->otherend_id, 
> virt_to_gfn(ring->intf), 0);
> + ring->bytes = (void*)__get_free_pages(GFP_KERNEL | __GFP_ZERO,
> + XEN_9PFS_RING_ORDER - (PAGE_SHIFT - XEN_PAGE_SHIFT));
> + if (ring->bytes == NULL)
> + goto out;
> + for (i = 0; i < (1 << XEN_9PFS_RING_ORDER); i++)
> + ring->intf->ref[i] = 
> gnttab_grant_foreign_access(dev->otherend_id, virt_to_gfn(ring->bytes) + i, 
> 0);

You need to handle gnttab_grant_foreign_access() returning an error. For
ring->ref too.

(and maybe wrap the line above)

> + ring->ring.in = ring->bytes;

ring->ring? Maybe 'dataring' for the top-level structure?

BTW, do we really need 'bytes' member? It's always 'ring.in' AFAICT. You
could make it a union with 'ring' (the second 'ring' ;-)) if you want to
keep a pointer to the whole thing as a dedicated name.

-boris


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

Re: [Xen-devel] [PATCH v2 3/7] xen/9pfs: introduce Xen 9pfs transport driver

[Boris Ostrovsky]

On 03/08/2017 06:58 PM, Stefano Stabellini wrote:
> Introduce the Xen 9pfs transport driver: add struct xenbus_driver to
> register as a xenbus driver and add struct p9_trans_module to register
> as v9fs driver.
>
> All functions are empty stubs for now.
>
> Signed-off-by: Stefano Stabellini 
> CC: boris.ostrov...@oracle.com
> CC: jgr...@suse.com
> CC: Eric Van Hensbergen 
> CC: Ron Minnich 
> CC: Latchesar Ionkov 
> CC: v9fs-develo...@lists.sourceforge.net
> ---
>  net/9p/trans_xen.c | 101 
> +
>  1 file changed, 101 insertions(+)
>  create mode 100644 net/9p/trans_xen.c
>
> diff --git a/net/9p/trans_xen.c b/net/9p/trans_xen.c
> new file mode 100644
> index 000..877dfd0
> --- /dev/null
> +++ b/net/9p/trans_xen.c
> @@ -0,0 +1,101 @@
> +/*
> + * linux/fs/9p/trans_xen
> + *
> + * Xen transport layer.

Does this need full copyright header?

Either way

Reviewed-by: Boris Ostrovsky 




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

[Xen-devel] [PATCH 4/4] misc/branching-checklist: Call mg-branch-setup in Cambridge too

[Ian Jackson]

Signed-off-by: Ian Jackson 
---
 misc/branching-checklist.txt | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/misc/branching-checklist.txt b/misc/branching-checklist.txt
index c905383..8899432 100644
--- a/misc/branching-checklist.txt
+++ b/misc/branching-checklist.txt
@@ -54,6 +54,12 @@ ov=4.0
OSSTEST_CONFIG=production-config ./mg-branch-setup xen-$v-testing bisect
OSSTEST_CONFIG=production-config ./mg-branch-setup 
qemu-upstream-$v-testing bisect
 
+# make branches etc. in Cambridge osstest
+ssh osst...@osstest.xs.citrite.net
+   cd testing.git
+   OSSTEST_CONFIG=production-config-cambridge ./mg-branch-setup 
xen-$v-testing bisect
+   OSSTEST_CONFIG=production-config-cambridge ./mg-branch-setup 
qemu-upstream-$v-testing bisect
+
 * add branch to osstest
 ie add both eg qemu-upstream-4.2-testing and xen-4.2-testing to 
BRANCHES in cr-for-branches
 
-- 
2.1.4


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

Re: [Xen-devel] [PATCH v16 4/9] x86: add multiboot2 protocol support for EFI platforms

[Daniel Kiper]

On Tue, Mar 07, 2017 at 12:39:04AM +0100, Daniel Kiper wrote:
> On Wed, Feb 22, 2017 at 09:04:17AM -0800, Doug Goldstein wrote:
>
> [...]
>
> > I'm currently at ELC and then on vacation so I don't have access to any
> > of the machines currently myself. However the machine I most use to test
> > is a NUC5i5MYHE and a NUC5i3MYHE if you want to ask around if someone
> > has one internally. But that's why I gave QEMU as an example.
> >
> > I was using qemu master from a few weeks ago. I'll have to find the
> > revision for you. But the command line I use is:
> >
> > -enable-kvm -M pc-q35-2.8 -device intel-iommu -cpu host -m 2048 -smp 2
> > -drive if=pflash,format=raw,file=/tmp/tmp.EiR6ixmYzV -global
> > isa-debugcon.iobase=0x402 -debugcon file:/tmp/tmp.nuvEXUWfnA -monitor
> > stdio -chardev socket,host=127.0.0.1,port=25914,id=S0,server,nowait
> > -device isa-serial,chardev=S0 -device piix3-usb-uhci -device usb-tablet
> > -netdev id=net0,type=tap -device
> > virtio-net-pci,netdev=net0,mac=52:54:00:12:34:56 -boot order=n -device
> > qxl-vga -gdb tcp::14952
>
> Sadly, my colleagues and I are not able to reproduce the problem on any of
> machines available for us (available on the market and some development
> stuff in our labs). I did tests with QEMU (I am not able to run it with
> "-device intel-iommu" on my machine; I have to investigate this). Everything
> works. Joao did some tests on Intel NUC D34010WYK second generation.
> Everything works. So, Konrad ordered Intel NUC NUC5i3MYHE for me. I am
> waiting for delivery. Doug, could you tell me what distro, Xen, etc. you
> have installed on that NUC? I would like to test same config as yours on
> this machine.

Latest QEMU from git with intel-iommu device enabled works without any issue.
Though it looks that I found a bug in Xen IOMMU code. If I run Xen from master
in QEMU then QEMU complains and crashes:

  qemu-system-x86_64: /srv/dev/qemu/qemu_20170308/hw/i386/intel_iommu.c:1786: 
vtd_mem_write: Assertion `size == 4' failed.
  Aborted (core dumped)

So, I took a look at dma_msi_set_affinity() and found this:

  dmar_writeq(iommu->reg, DMAR_FEADDR_REG, msg.address);

It looks bogus because DMAR_FEADDR_REG is defined in spec as 32-bit wide.
So, applied this patch:

-dmar_writeq(iommu->reg, DMAR_FEADDR_REG, msg.address);
+dmar_writel(iommu->reg, DMAR_FEADDR_REG, msg.address_lo);
+if (x2apic_enabled)
+dmar_writel(iommu->reg, DMAR_FEUADDR_REG, msg.address_hi);

Ant it looks that right now everything works.

If patch make sense I can post it with proper commit message.

Daniel

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

[Xen-devel] [PATCH 2/4] misc/release-checklist: Remove pre-4.3 tarball target instructions

[Ian Jackson]

4.2 is well out of support and we will never need to make a release of
it again.  Delete all the stuff for making combined tarballs "by hand".

Signed-off-by: Ian Jackson 
---
 misc/release-checklist.txt | 34 --
 1 file changed, 34 deletions(-)

diff --git a/misc/release-checklist.txt b/misc/release-checklist.txt
index dfeb34a..0fa50c9 100644
--- a/misc/release-checklist.txt
+++ b/misc/release-checklist.txt
@@ -190,40 +190,10 @@ RELEASE TARBALL
mkdir /volatile/iwj/website-thing/xen.org/oss-xen/release/$v
mv dist/xen-$v.tar.gz 
/volatile/iwj/website-thing/xen.org/oss-xen/release/$v/.
 
-#hg archive -t files /volatile/iwj/d/xen-$v
-
-cd /u/iwj/work/xen.git
-mkdir /volatile/iwj/d/xen-$v
-git archive --format=tar RELEASE-$v |tar Cxf /volatile/iwj/d/xen-$v -
-[OR FOR RCs
-git archive --format=tar $v |tar Cxf /volatile/iwj/d/xen-$v -
-]
-
-cd /volatile/iwj/d/xen-$v/tools/
-mkdir ioemu-qemu-xen   # 4.0, 4.1
-mkdir qemu-xen qemu-xen-traditional  # 4.2+
-
-cd /u/iwj/work/1/qemu-iwj.git
-git-archive --format=tar xen-$v |tar Cxf 
/volatile/iwj/d/xen-$v/tools/ioemu-qemu-xen -   # 4.0, 4.1
-git-archive --format=tar xen-$v |tar Cxf 
/volatile/iwj/d/xen-$v/tools/qemu-xen-traditional -   # 4.2+
-
-cd /u/iwj/work/1/qemu-upstream.git # now we have a merged tree
-git-pull
-git-archive --format=tar qemu-xen-$v |tar Cxf 
/volatile/iwj/d/xen-$v/tools/qemu-xen -   # 4.2+
-
-cd ..
-# ONE OF:
-ssh xenbits.xen.org cat /home/xen/release-checklist.patch-4.2 | patch Config.mk
-ssh xenbits.xen.org cat /home/xen/release-checklist.patch-4.1 | patch -p1 
Config.mk
-ssh xenbits.xen.org cat /home/xen/release-checklist.patch-4.0 | patch -p1 
Config.mk
-
 # website-thing is cvs -d 
hg.uk.xensource.com:/usr/groups/sources/cvs/akamai co xen.org
cd /volatile/iwj/website-thing/xen.org
mkdir oss-xen/release/$v
 
-cd ..
-GZIP=-9v tar zcf 
/volatile/iwj/website-thing/xen.org/oss-xen/release/$v/xen-$v.tar.gz xen-$v
-
 # test build
 cd /volatile/iwj/d
 mkdir build
@@ -232,14 +202,10 @@ GZIP=-9v tar zcf 
/volatile/iwj/website-thing/xen.org/oss-xen/release/$v/xen-$v.t
 #rsync -a --delete xen-$v build/
 cd xen-$v
 export http_proxy=http://localhost:3128/
-(make -j4 KERNELS='' && echo ok.) 2>&1 | tee ../log.$v 
 # pre 4.2
 (./configure && make -j4 KERNELS='' && echo ok.) 2>&1 | tee 
../log.$v   # post 4.2
 
 # [[ test build amd64 ]]
 
-### check that tarball's .hgtags has the release tag put there by Keir
-##tar zvvxOf 
/volatile/iwj/website-thing/xen.org/oss-xen/release/$v/xen-$v.tar.gz 
xen-$v/.hgtags |less
-
cvs add -kb oss-xen/release/$v/
 
 cd oss-xen/release/$v
-- 
2.1.4


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

[Xen-devel] [PATCH 1/4] misc/release-checklist: Remove clearly-obsolete stuff

[Ian Jackson]

Remove:

 - Head comment saying not to edit here.  This came from the
   now-no-longer-master xenbits copy which I have deleted.

 - Many old (commented-out) instruction related to hg

 - Many old (commented-out) instruction related to pre-unified
   qemu trees.

 - Many old (commented-out) instruction related to ancient
   locations within Citrix.

Signed-off-by: Ian Jackson 
---
 misc/release-checklist.txt | 64 --
 1 file changed, 64 deletions(-)

diff --git a/misc/release-checklist.txt b/misc/release-checklist.txt
index 51f9508..dfeb34a 100644
--- a/misc/release-checklist.txt
+++ b/misc/release-checklist.txt
@@ -1,9 +1,3 @@
-DO NOT EDIT
-
-BEING INCORPORATED INTO GIT
-
-
-
 v=4.1
 ov=4.0
 
@@ -14,17 +8,6 @@ ov=4.0
 * make branch in qemu-iwj.git
 git-branch $v-testing master
 
-#* make branches in /usr/groups/xencore/HG (xen.hg and qemu.git)
-#cd /usr/groups/xencore/HG
-#really rsync -aH xen-unstable.hg/. xen-$v-testing.hg &
-#really rsync -aH qemu-xen-unstable.git/. qemu-xen-$v-testing.git &
-#
-#ed xen-$v-testing.hg/.hg/hgrc
-#/unsta
-#s/unstable/###4.1###-testing
-#w
-#q
-
 # make branches in xenbits.xen.org qemus
 ssh x...@xenbits.xen.org
cd ~/git/qemu-xen.git
@@ -32,17 +15,6 @@ ov=4.0
git branch stable-$v master
cd ~/git/qemu-xen-traditional.git
git branch stable-$v master
-#cd ~/git
-#rsync -aH qemu-xen-unstable.git/. qemu-xen-$v-testing.git &
-#rsync -aH qemu-upstream-unstable.git/. qemu-upstream-$v-testing.git &
-#cd staging
-#rsync -aH qemu-xen-unstable.git/. qemu-xen-$v-testing.git &
-#rsync -aH qemu-upstream-unstable.git/. qemu-upstream-$v-testing.git &
-#cd /var/xenbits-www/html/git-http
-#ln -sf /home/xen/git/qemu-xen-$v-testing.git .
-#ln -sf /home/xen/git/staging/qemu-xen-$v-testing.git staging/.
-#ln -sf /home/xen/git/qemu-upstream-$v-testing.git .
-#ln -sf /home/xen/git/staging/qemu-upstream-$v-testing.git staging/.
 
 # make branch in libvirt
 ssh x...@xenbits.xen.org
@@ -55,15 +27,6 @@ ov=4.0
git branch staging-$v staging
git branch stable-$v master
 
-## make hg mirror branch(es)
-#  ssh r...@xenbits.xen.org
-#  cd ~xen/HG
-#  mkdir {staging/,}xen-$v-testing.hg
-#  chown git2hg:git2hg {staging/,}xen-$v-testing.hg
-# # edit list of repos to mirror - Anthony Perard, or:
-#  ed ~git2hg/update-hg-mirror.sh
-#  /all_xen_version
-
 # update xendocs@xenbits docs generator to generate new stable branch
 #  docs too. commit to git.
 * make 13:37  http://xenbits.xen.org/docs/4.2-testing/ is now live true
@@ -103,10 +66,6 @@ ov=4.0
 cp qemu-xen--master.patchbot-reported-heads  
qemu-xen--stable-$v.patchbot-reported-heads
 cp qemu-xen--staging.patchbot-reported-heads  
qemu-xen--staging-$v.patchbot-reported-heads
 cp qemu-xen-traditional--master.patchbot-reported-heads 
qemu-xen-traditional--stable-$v.patchbot-reported-heads
-#cd staging/
-##  cp xen-unstable.last xen-$v-testing.last
-##  cp xen-unstable.last xen-$v-testing.last
-#cd ..
 
 #emacs versions
perl -i~ -pe 'next unless m/\b\Q'$ov'\E\b/; $x=$_; $x=~ 
s/\b\Q'$ov'\E\b/'$v'/g; print $x;' versions
@@ -128,9 +87,6 @@ which should produce no output.  Replace as necessary.
 
 Update new stable tree's MAINTAINERS to contain correct info for this stable 
branch
 
-##* update wiki page
-##http://wiki.xen.org/xenwiki/XenRepositories
-
 ###* fix new trees' vcs descriptions
 #* make old trees' descriptions "historical"
 #  cd ~/git
@@ -145,8 +101,6 @@ Update new stable tree's MAINTAINERS to contain correct 
info for this stable bra
 
 * make tag in qemu-iwj.git
 
-##* push qemu tag in /usr/groups/xencore/HGgit-update-server-info
-##* push qemu tag in /usr/groups/xencore/patchman  
git-update-server-info
 * push qemu tag in xenbits.xen.org git-update-server-info
 * push qemu tag in xenbits.xen.org staging git-update-server-info
 
@@ -177,13 +131,7 @@ t=RELEASE-$r
   git-checkout $s
   git-tag -u 'Xen.org Xen tree code signing' -m "Xen $v" xen-$v $s
 
-#  git-push ianj@docr-01:/usr/groups/xencore/HG/qemu-xen-$b.git $s:master 
xen-$v   # 4.1 and earlier only
-#  git-push latara:/usr/groups/xencore/patchman/qemu-xen-$b.git $s:master 
xen-$v
   git-push xenbits.xen.org:/home/xen/git/qemu-xen-traditional.git $s:stable-$x 
xen-$v
-#  git-push x...@xenbits.xen.org:/home/xen/git/qemu-xen-$b.git $s:master xen-$v
-#  git-push x...@xenbits.xen.org:/home/xen/git/staging/qemu-xen-$b.git 
$s:master xen-$v
-#  ssh x...@xenbits.xen.org cd /home/xen/git/qemu-xen-$b.git '&&' git 
update-server-info
-#  ssh x...@xenbits.xen.org cd /home/xen/git/staging/qemu-xen-$b.git '&&' git 
update-server-info
 
 # consider making tag in minios, 

[Xen-devel] [PATCH 3/4] misc/release-checklist: Split out branching-checklist.txt

[Ian Jackson]

This is almost all just motion.  There is one new paragraph in
branching-checklist.txt:

+ Update both new branches according to release-checklist.txt section re
+ README etc.

Signed-off-by: Ian Jackson 
---
 misc/branching-checklist.txt | 97 
 misc/release-checklist.txt   | 95 ---
 2 files changed, 97 insertions(+), 95 deletions(-)
 create mode 100644 misc/branching-checklist.txt

diff --git a/misc/branching-checklist.txt b/misc/branching-checklist.txt
new file mode 100644
index 000..c905383
--- /dev/null
+++ b/misc/branching-checklist.txt
@@ -0,0 +1,97 @@
+v=4.1
+ov=4.0
+
+##* tag branchpoint
+##hg tag $v.0-branched
+##hg sign -k 'Xen tree' 4.1.0-branched
+
+* make branch in qemu-iwj.git
+git-branch $v-testing master
+
+# make branches in xenbits.xen.org qemus
+ssh x...@xenbits.xen.org
+   cd ~/git/qemu-xen.git
+   git branch staging-$v staging
+   git branch stable-$v master
+   cd ~/git/qemu-xen-traditional.git
+   git branch stable-$v master
+
+# make branch in libvirt
+ssh x...@xenbits.xen.org
+cd ~/git/libvirt.git/
+   git branch osstest/frozen/xen-$v-testing   xen-tested-master
+
+# make branches in xenbits.xen.org xen.git
+ssh x...@xenbits.xen.org
+cd ~/git/xen.git
+   git branch staging-$v staging
+   git branch stable-$v master
+
+# update xendocs@xenbits docs generator to generate new stable branch
+#  docs too. commit to git.
+* make 13:37  http://xenbits.xen.org/docs/4.2-testing/ is now live true
+#14:17  HOWTO: login to xenbits. become "xendocs" . cd cronjobs . edit
+#xenbits-docs-all.sh in the obvious way. git commit
+   ssh r...@xenbits.xen.org
+   su - xendocs
+   cd cronjobs
+   ed xenbits-docs-all.sh
+   /for branch
+   s/$/ 4.6-testing
+   # ^ OR SIMILAR
+   w
+   q
+git add -p
+   git commit -m "Branch for $v"
+
+### * make symlink on mariner for qemu
+###cd /var/www/git/
+###ln -s /usr/groups/xencore/HG/qemu-xen-$v-testing.git .
+
+* make branches etc. in osstest
+ssh osst...@osstest.test-lab
+   cd testing.git
+   OSSTEST_CONFIG=production-config ./mg-branch-setup xen-$v-testing bisect
+   OSSTEST_CONFIG=production-config ./mg-branch-setup 
qemu-upstream-$v-testing bisect
+
+* add branch to osstest
+ie add both eg qemu-upstream-4.2-testing and xen-4.2-testing to 
BRANCHES in cr-for-branches
+
+* add to patchbot
+on xenbits
+cd ~/HG/patchbot/
+
+   cp xen--master.patchbot-reported-heads 
xen--stable-$v.patchbot-reported-heads
+   cp xen--staging.patchbot-reported-heads 
xen--staging-$v.patchbot-reported-heads
+cp qemu-xen--master.patchbot-reported-heads  
qemu-xen--stable-$v.patchbot-reported-heads
+cp qemu-xen--staging.patchbot-reported-heads  
qemu-xen--staging-$v.patchbot-reported-heads
+cp qemu-xen-traditional--master.patchbot-reported-heads 
qemu-xen-traditional--stable-$v.patchbot-reported-heads
+
+#emacs versions
+   perl -i~ -pe 'next unless m/\b\Q'$ov'\E\b/; $x=$_; $x=~ 
s/\b\Q'$ov'\E\b/'$v'/g; print $x;' versions
+git diff
+   git add versions
+   git commit -m "Branch for $v"
+
+#* update xenbits web page
+ssh r...@xenbits.xen.org
+cd /var/xenbits-www/html
+emacs index.html
+   # - search for previous version number, and update in each place found
+   # - in general, drop one old release in favour of the new one
+
+Ensure references to qemu trees in xen.git's Config.mk are updated.
+Check this with
+grep unstable Config.mk 
+which should produce no output.  Replace as necessary.
+
+Update both new branches according to release-checklist.txt section re
+README etc.
+
+Update new stable tree's MAINTAINERS to contain correct info for this stable 
branch
+
+###* fix new trees' vcs descriptions
+#* make old trees' descriptions "historical"
+#  cd ~/git
+#  perl -i~ -pe "s/unstable/4.6-testing/" 
qemu-upstream-$v-testing.git/description
+
diff --git a/misc/release-checklist.txt b/misc/release-checklist.txt
index 0fa50c9..4784256 100644
--- a/misc/release-checklist.txt
+++ b/misc/release-checklist.txt
@@ -1,98 +1,3 @@
-v=4.1
-ov=4.0
-
-##* tag branchpoint
-##hg tag $v.0-branched
-##hg sign -k 'Xen tree' 4.1.0-branched
-
-* make branch in qemu-iwj.git
-git-branch $v-testing master
-
-# make branches in xenbits.xen.org qemus
-ssh x...@xenbits.xen.org
-   cd ~/git/qemu-xen.git
-   git branch staging-$v staging
-   git branch stable-$v master
-   cd ~/git/qemu-xen-traditional.git
-   git branch stable-$v master
-
-# make branch in libvirt
-ssh x...@xenbits.xen.org
-cd ~/git/libvirt.git/
-   git branch osstest/frozen/xen-$v-testing   xen-tested-master
-
-# make branches in 

[Xen-devel] [PATCH 0/4] misc/release-checklist: Updates prompted by recent release

[Ian Jackson]

When doing the recent stable release branches, I tripped over some
deficiencies in these checklists.  And, now that they are in git, we
can much more safely throw away a lot of ancient stuff.

Please shout if you have any objections.  I hope to push this today.

Ian.

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

Re: [Xen-devel] [PATCH v8 18/24] x86: L2 CAT: implement get hw info flow.

[Jan Beulich]

>>> On 15.02.17 at 09:49,  wrote:
> +static bool l2_cat_get_feat_info(const struct feat_node *feat,
> + uint32_t data[], uint32_t array_len)
> +{
> +if ( !data || 2 > array_len )
> +return false;
> +
> +data[CBM_LEN] = feat->info.l2_cat_info.cbm_len;
> +data[COS_MAX] = feat->info.l2_cat_info.cos_max;

What about PSR_FLAG? Which puts under question the
array_len check at the start of this and its sibling functions: If
more array entries are provided, they'd all be left uninitialized
without the caller having a way to know. Coming back to the
data structures being the same for all features, there should
presumably be a structure instead of an array be used for
communication here, and ...

> @@ -754,6 +755,11 @@ struct xen_sysctl_psr_cat_op {
>  #define XEN_SYSCTL_PSR_CAT_L3_CDP   (1u << 0)
>  uint32_t flags; /* OUT: CAT flags */
>  } l3_info;
> +
> +struct {
> +uint32_t cbm_len;   /* OUT: CBM length */
> +uint32_t cos_max;   /* OUT: Maximum COS */
> +} l2_info;

... this should use the same structure as l3_info (flags being
set to zero until a use arises). This would then also allow for
more code to be shared instead of duplicated.

Jan


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

[Xen-devel] Xen 4.8.0 dom0pvh=1 causes ext4 filesystem corruption

[Valtteri Kiviniemi]

Hi,

Yesterday I decided to upgrade my Xen version from 4.6.0 to 4.8.0. I
compiled it from source and at the same time I compiled the latest Linux
kernel (4.10.1).

When rebooting I decided to try if dom0 PVH would work (with previous Xen
version it just caused kernel panic). Seemed to boot fine until systemd
started mounting the root filesystem and then the console was filled with
ext4 errors. Couldn't even log in.

Booting with a systemrescuecd and running fsck just caused the whole
filesystem to be re-attached in thousands of small pieces under lost+found.
I was sure that this was a some kind of hardware failure, so I switched my
hard drives and did a clean reinstall for dom0 and tried again. Again,
after a reboot the whole rootfs was completely corrupted.

Second reinstall and this time I disabled dom0 PVH and the system booted
just fine, and no ext4 errors. My root filesystem is just a simple Linux
software raid1 with ext4 on top of it.

Now that I started thinking I have also had strange ext4 errors happening
inside my guests, so I also disabled PVH from all the guests. With guests
the ext4 error is always the same: "EXT4-fs error (device xvda1):
ext4_iget:4665: inode #317: comm find: bogus i_mode (135206)"

Unfortunately I don't have any logs from the dom0 corruption as I can't
even log in to the system when dom0 PVH is enabled. The corruption happens
instantly during system bootup.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v8 17/24] x86: L2 CAT: implement CPU init and free flow.

[Jan Beulich]

>>> On 15.02.17 at 09:49,  wrote:
> @@ -684,6 +686,53 @@ struct feat_ops l3_cdp_ops = {
>  .write_msr = l3_cdp_write_msr,
>  };
>  
> +/* L2 CAT callback functions implementation. */
> +static void l2_cat_init_feature(struct cpuid_leaf regs,

const struct cpuid_leaf * (and of course I should have noticed this
already in earlier patches, but I didn't)

> +struct feat_node *feat,
> +struct psr_socket_info *info)
> +{
> +struct psr_cat_hw_info l2_cat = { };

I realize Konrad did ask for the initializer here, but it's really pointless
to have such when both structure fields get very obviously set right
below. If you want an initializer, just set the fields to their final values.

> +unsigned int socket;
> +
> +/* No valid values so do not enable the feature. */
> +if ( !regs.a || !regs.d )
> +return;
> +
> +l2_cat.cbm_len = (regs.a & CAT_CBM_LEN_MASK) + 1;
> +l2_cat.cos_max = min(opt_cos_max, regs.d & CAT_COS_MAX_MASK);
> +
> +/* cos=0 is reserved as default cbm(all ones). */
> +feat->cos_reg_val[0] = (1ull << l2_cat.cbm_len) - 1;
> +
> +feat->feature = PSR_SOCKET_L2_CAT;
> +ASSERT(!test_bit(PSR_SOCKET_L2_CAT, >feat_mask));
> +__set_bit(PSR_SOCKET_L2_CAT, >feat_mask);
> +
> +feat->info.l2_cat_info = l2_cat;
> +
> +info->nr_feat++;

Is this field really used for anything? I don't recall seeing other than
these increments.

Jan


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

Re: [Xen-devel] [PATCH v8 13/24] x86: refactor psr: implement CPU init and free flow for CDP.

[Jan Beulich]

>>> On 15.02.17 at 09:49,  wrote:
> --- a/xen/arch/x86/psr.c
> +++ b/xen/arch/x86/psr.c
> @@ -97,6 +97,7 @@ struct psr_cat_hw_info {
>  struct feat_hw_info {
>  union {
>  struct psr_cat_hw_info l3_cat_info;
> +struct psr_cat_hw_info l3_cdp_info;

Two union members of the same type? What's the union good for
then? (I've peeked ahead, and L2 CAT adds yet another one. A
strong sign that you've gone too far with what needs to be per-
feature vs what can be common.)

> @@ -195,6 +196,22 @@ struct feat_node {
>  struct list_head list;
>  };
>  
> +/*
> + * get_data - get DATA COS register value from input COS ID.
> + * @feat:the feature list entry.
> + * @cos: the COS ID.
> + */
> +#define get_cdp_data(feat, cos)  \
> +( feat->cos_reg_val[cos * 2] )

Stray blanks inside parentheses. Macro parameters need to be
parenthesized.

> +/*
> + * get_cdp_code - get CODE COS register value from input COS ID.
> + * @feat:the feature list entry.
> + * @cos: the COS ID.
> + */
> +#define get_cdp_code(feat, cos)  \
> +( feat->cos_reg_val[cos * 2 + 1] )

Same here.

> @@ -1213,12 +1288,21 @@ static void cpu_init_work(void)
>  {
>  cpuid_count_leaf(PSR_CPUID_LEVEL_CAT, 1, );
>  
> -feat = feat_l3_cat;
> -/* psr_cpu_prepare will allocate it on subsequent CPU onlining. */
> -feat_l3_cat = NULL;
> -feat->ops = l3_cat_ops;
> -
> -l3_cat_init_feature(regs, feat, info);
> +if ( (regs.c & PSR_CAT_CDP_CAPABILITY) && (opt_psr & PSR_CDP) &&
> + !test_bit(PSR_SOCKET_L3_CDP, >feat_mask) )
> +{
> +feat = feat_l3_cdp;
> +/* psr_cpu_prepare will allocate it on subsequent CPU onlining. 
> */
> +feat_l3_cdp = NULL;
> +feat->ops = l3_cdp_ops;
> +l3_cdp_init_feature(regs, feat, info);
> +} else {

I think someone else has already pointed out the style issue here, so
just in case ...

> @@ -1267,6 +1351,14 @@ static int psr_cpu_prepare(void)
>   (feat_l3_cat = xzalloc(struct feat_node)) == NULL )
>  return -ENOMEM;
>  
> +if ( feat_l3_cdp == NULL &&
> + (feat_l3_cdp = xzalloc(struct feat_node)) == NULL )
> +{
> +xfree(feat_l3_cat);
> +feat_l3_cat = NULL;

Why the freeing? We've decided to allow for one node to be kept,
so no reason to free it on the error path here.

Jan


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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. 
vs. 106534
 test-amd64-i386-xl-qemut-debianhvm-amd64 15 guest-localmigrate/x10 fail REGR. 
vs. 106534
 test-amd64-amd64-pygrub   9 debian-di-installfail REGR. vs. 106534
 test-amd64-i386-xl-raw  18 guest-start/debian.repeat fail REGR. vs. 106534
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail REGR. vs. 106534

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds  4 host-ping-check-native   fail REGR. vs. 106534
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 106534
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 106534
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 106534
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 106534
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 106534
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 106534
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 106534

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 build-arm64   5 xen-buildfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 build-arm64-xsm   5 xen-buildfail   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
 build-arm64-pvops 5 kernel-build fail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail 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-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   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-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  bd8451964078b006081fcef6d169961a3a6f746a
baseline version:
 xen  4036e7c592905c2292cdeba8269e969959427237

Last test of basis   106534  2017-03-07 19:14:51 Z1 days
Failing since106547  2017-03-08 08:59:30 Z1 days2 attempts
Testing same since   106561  2017-03-09 00:44:57 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Christoph Egger 
  Haozhong Zhang 

Re: [Xen-devel] [PATCH v8 11/24] x86: refactor psr: set value: implement cos id picking flow.

[Jan Beulich]

>>> On 15.02.17 at 09:49,  wrote:
> @@ -397,6 +408,25 @@ static int l3_cat_compare_val(const uint64_t val[],
>  return 0;
>  }
>  
> +static bool l3_cat_fits_cos_max(const uint64_t val[],
> +const struct feat_node *feat,
> +unsigned int cos)
> +{
> +uint64_t l3_def_cbm;
> +
> +l3_def_cbm = (1ull << feat->info.l3_cat_info.cbm_len) - 1;

Seeing this pattern recur I wonder whether this also wouldn't be
something that could be stored once in a generic manner, avoiding
the need for this per-feature callback (cos_max should be common
to all features too - not the values, but the abstract notion - so
perhaps get_cos_max() isn't needed as a callback either).

>  static int pick_avail_cos(const struct psr_socket_info *info,
>const uint64_t *val, uint32_t array_len,
>unsigned int old_cos,
>enum psr_feat_type feat_type)
>  {
> +unsigned int cos;
> +unsigned int cos_max = 0;
> +const struct feat_node *feat;
> +const unsigned int *ref = info->cos_ref;
> +
> +/*
> + * cos_max is the one of the feature which is being set.
> + */

This is a single line comment.

> +list_for_each_entry(feat, >feat_list, list)
> +{
> +if ( feat->feature != feat_type )
> +continue;
> +
> +cos_max = feat->ops.get_cos_max(feat);
> +if ( cos_max > 0 )
> +break;
> +}

I think I've seen this a number of times by now - please make this a
helper function, or store the result (which isn't going to change
afaict).

Other than these comments given to earlier patches apply here too,
as I think is obvious.

Jan


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

[Xen-devel] [xen-4.6-testing baseline-only test] 68646: regressions - trouble: blocked/broken/fail/pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 68646 xen-4.6-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68646/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i3864 host-build-prep   fail REGR. vs. 68608

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail   like 68608
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail   like 68608
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail   like 68608
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 68608
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 68608
 test-amd64-amd64-xl-qemut-winxpsp3  9 windows-install  fail like 68608

Tests which did not succeed, but are not blocking:
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-migrupgrade   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 build-i386-rumprun1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-3   63 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-2   63 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-5   63 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-4   63 xtf/test-pv32pae-xsa-194 fail   never pass
 test-armhf-armhf-xl-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   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-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  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-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 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
 

Re: [Xen-devel] [early RFC] ARM PCI Passthrough design document

[Julien Grall]

Hi Konrad,

On 09/03/17 11:17, Konrad Rzeszutek Wilk wrote:

On Thu, Mar 09, 2017 at 11:59:51AM +0900, Roger Pau Monné wrote:

On Wed, Mar 08, 2017 at 02:12:09PM -0500, Konrad Rzeszutek Wilk wrote:

On Wed, Mar 08, 2017 at 07:06:23PM +, Julien Grall wrote:

Hi,

On 02/02/17 23:06, Stefano Stabellini wrote:

On Thu, 2 Feb 2017, Julien Grall wrote:

On 01/02/17 10:55, Roger Pau Monné wrote:

On Wed, Jan 25, 2017 at 06:53:20PM +, Julien Grall wrote:

On 24/01/17 20:07, Stefano Stabellini wrote:

On Tue, 24 Jan 2017, Julien Grall wrote:

For DT, I would have a fallback on mapping the root complex to DOM0 if we
don't support it. So DOM0 could still use PCI.

For ACPI, I am expecting all the platform ECAM compliant or require few
quirks. So I would mandate the support of the root complex in Xen in order to
get PCI supported.


Sound good. Ack.


I am currently rewriting the design document to take into account all the
comments and follow the path to have the host bridge in Xen and DOM0 will
get an emulated one.

I began to look at scanning and configuring PCI devices in Xen. Looking at
the PCI firmware specification, the firmware is not required to configure
the BAR register other than for boot and console devices. This means an
Operating System (or the hypervisor in our case) may have to configure some
devices.

In order to configure the BAR register, Xen would need to know where are the
PCI resources. On ACPI they can be found in ASL, however Xen is not able to
parse it. In the case of Device Tree with can retrieve the PCI resources
using the property "ranges".

I can see a couple of solutions:
1# Rely on DOM0 to do the PCI configuration. This means that DOM0 should
see all the PCI devices and therefore will not be possible to hide from DOM0
if we know at boot a device will be used by a guest (i.e something similar
to pciback.hide but directly handled in Xen).


.. this as for SR-IOV devices you need the drivers to kick the hardware
to generate the new bus addresses. And those (along with the BAR regions) are
not visible in ACPI (they are constructued dynamically).


There's already code in Xen [0] to find out the size of the BARs of SR-IOV
devices, but I'm not sure what's the intended usage of that, does it need to
happen _after_ the driver in Dom0 has done whatever magic for this to work?


Yes. This is called via the PHYSDEVOP_pci_device_add hypercall when
the device driver in dom0 has finished "creating" the VF. See drivers/xen/pci.c


We are thinking to not use PHYSDEVOP_pci_device_add hypercall for ARM 
and do the PCI scanning in Xen.


If I understand correctly what you said, only the PCI driver will be 
able to kick SR-IOV device and Xen would not be able to detect the 
device until it has been fully configured. So it would mean that we have 
to keep PHYSDEVOP_pci_device_add around to know when Xen can use the device.


Am I correct?

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

[Michal Hocko]

On Tue 07-03-17 13:40:04, Igor Mammedov wrote:
> On Mon, 6 Mar 2017 15:54:17 +0100
> Michal Hocko  wrote:
> 
> > On Fri 03-03-17 18:34:22, Igor Mammedov wrote:
[...]
> > > in current mainline kernel it triggers following code path:
> > > 
> > > online_pages()
> > >   ...
> > >if (online_type == MMOP_ONLINE_KERNEL) {   
> > >   
> > > if (!zone_can_shift(pfn, nr_pages, ZONE_NORMAL, 
> > > _shift))
> > > return -EINVAL;  
> > 
> > Are you sure? I would expect MMOP_ONLINE_MOVABLE here
> pretty much, reproducer is above so try and see for yourself

I will play with this...
 
[...]
> > > get_maintainer.pl doesn't lists linux-api for 31bc3858ea3e,
> > > MAINTAINERS should be fixed if linux-api were to be CCed.  
> > 
> > user visible APIs _should_ be discussed at this mailing list regardless
> > what get_maintainer.pl says. This is not about who is the maintainer but
> > about getting as wide audience for things that would have to be
> > maintained basically for ever.
>
> How would random contributor know which list to CC?

This should have been brought up during the review process which was
less than sufficient in this case.

> > > > So unless this causes a major regression which would be hard to fix I
> > > > will submit the patch for inclusion.  
> > > it will be a major regression due to lack of daemon that
> > > could online fast and can't be killed on OOM. So this
> > > clean up patch does break used feature without providing
> > > a viable alternative.  
> > 
> > So let's discuss the current memory hotplug shortcomings and get rid of
> > the crud which developed on top. I will start by splitting up the patch
> > into 3 parts. Do the auto online thing from the HyperV and xen balloning
> > drivers and dropping the config option and finally drop the sysfs knob.
> > The last patch might be NAKed and I can live with that as long as the
> > reasoning is proper and there is a general consensus on that.
> PS: CC me on that patches too
> 
> It's major regression if you remove auto online in kernels that
> run on top of x86 kvm/vmware hypervisors, making API cleanups
> while breaking useful functionality doesn't make sense.
> 
> I would ACK config option removal if auto online keeps working
> for all x86 hypervisors (hyperv/xen isn't the only who needs it)
> and keep kernel CLI option to override default.
> 
> That doesn't mean that others will agree with flipping default,
> that's why config option has been added.
> 
> Now to sum up what's been discussed on this thread, there were 2
> different issues discussed:
>   1) memory hotplug: remove in kernel auto online for all
>  except of hyperv/xen
> 
>- suggested RFC is not acceptable from virt point of view
>  as it regresses guests on top of x86 kvm/vmware which
>  both use ACPI based memory hotplug.
> 
>- udev/userspace solution doesn't work in practice as it's
>  too slow and unreliable when system is under load which
>  is quite common in virt usecase. That's why auto online
>  has been introduced in the first place.

Please try to be more specific why "too slow" is a problem. Also how
much slower are we talking about?
 
>   2) memory unplug: online memory as movable
> 
>- doesn't work currently with udev rule due to kernel
>  issues https://bugzilla.redhat.com/show_bug.cgi?id=1314306#c7

These should be fixed
 
>- could be fixed both for in kernel auto online and udev
>  with following patch:
>  https://bugzilla.redhat.com/attachment.cgi?id=1146332
>  but fixing it this way exposes zone disbalance issues,
>  which are not present in current kernel as blocks are
>  onlined in Zone Normal. So this is area to work and
>  improve on.
> 
>- currently if one wants to use online_movable,
>  one has to either
>* disable auto online in kernel OR

which might not just work because an unmovable allocation could have
made the memblock pinned.

>* remove udev rule that distro ships
>  AND write custom daemon that will be able to online
>  block in right zone/order. So currently whole
>  online_movable thing isn't working by default
>  regardless of who onlines memory.

my epxperience with onlining full nodes as movable shows this works just
fine (with all the limitations of the movable zones but that is a
separate thing). I haven't played with configurations where movable
zones are sharing the node with other zones.

>  I'm in favor of implementing that in kernel as it keeps
>  kernel internals inside kernel and doesn't need
>  kernel API to be involved (memory blocks in sysfs,
>  online_kernel, online_movable)
>  There would be no need in userspace which would have to
>  deal with kernel zoo and maintain that as 

[Xen-devel] [distros-debian-wheezy test] 68647: tolerable trouble: broken/pass

[Platform Team regression test user]

flight 68647 distros-debian-wheezy real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68647/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 build-arm64   2 hosts-allocate   broken never pass
 build-arm64-pvops 2 hosts-allocate   broken never pass
 build-arm64-pvops 3 capture-logs broken never pass
 build-arm64   3 capture-logs broken never pass

baseline version:
 flight   68607

jobs:
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-arm64-pvopsbroken  
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-wheezy-netboot-pvgrub pass
 test-amd64-i386-i386-wheezy-netboot-pvgrub   pass
 test-amd64-i386-amd64-wheezy-netboot-pygrub  pass
 test-amd64-amd64-i386-wheezy-netboot-pygrub  pass



sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

Logs, config files, etc. are available at
http://osstest.xs.citrite.net/~osstest/testlogs/logs

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


Push not applicable.


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

Re: [Xen-devel] [PATCH RFC] x86emul: suppress reads for unhandled 0f38/0f3a extension space insns

[Andrew Cooper]

On 09/03/17 10:20, Jan Beulich wrote:
> The way these extension spaces get handled we so far always end up
> going through the generic SrcMem operand fetch path for unused table
> entries. Suppress actual memory accesses happening by forcing op_bytes
> to zero in those cases.
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

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

[Xen-devel] [qemu-mainline test] 106559: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 106544
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 106544
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 106544
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 106544
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 106544
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 106544

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 build-arm64   5 xen-buildfail   never pass
 build-arm64-xsm   5 xen-buildfail   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-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 build-arm64-pvops 5 kernel-build fail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  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-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass

version targeted for testing:
 qemuub64842dee42d6b24d51283e4722140b73be1e222
baseline version:
 qemuu43c227f9dd7945bb4a895f841ecdb957bd8a12da

Last test of basis   106544  2017-03-08 05:48:50 Z1 days
Testing same since   106559  2017-03-08 22:14:58 Z0 days1 attempts


People who touched revisions under test:
  Daniel P. Berrange 
  Fam Zheng 
  Kevin Wolf 
  Markus Armbruster 
  Peter Maydell 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  fail
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64 

Re: [Xen-devel] [early RFC] ARM PCI Passthrough design document

[Konrad Rzeszutek Wilk]

On Thu, Mar 09, 2017 at 11:59:51AM +0900, Roger Pau Monné wrote:
> On Wed, Mar 08, 2017 at 02:12:09PM -0500, Konrad Rzeszutek Wilk wrote:
> > On Wed, Mar 08, 2017 at 07:06:23PM +, Julien Grall wrote:
> > > Hi,
> > > 
> > > On 02/02/17 23:06, Stefano Stabellini wrote:
> > > > On Thu, 2 Feb 2017, Julien Grall wrote:
> > > > > On 01/02/17 10:55, Roger Pau Monné wrote:
> > > > > > On Wed, Jan 25, 2017 at 06:53:20PM +, Julien Grall wrote:
> > > > > > > On 24/01/17 20:07, Stefano Stabellini wrote:
> > > > > > > > On Tue, 24 Jan 2017, Julien Grall wrote:
> > > > > For DT, I would have a fallback on mapping the root complex to DOM0 
> > > > > if we
> > > > > don't support it. So DOM0 could still use PCI.
> > > > > 
> > > > > For ACPI, I am expecting all the platform ECAM compliant or require 
> > > > > few
> > > > > quirks. So I would mandate the support of the root complex in Xen in 
> > > > > order to
> > > > > get PCI supported.
> > > > 
> > > > Sound good. Ack.
> > > 
> > > I am currently rewriting the design document to take into account all the
> > > comments and follow the path to have the host bridge in Xen and DOM0 will
> > > get an emulated one.
> > > 
> > > I began to look at scanning and configuring PCI devices in Xen. Looking at
> > > the PCI firmware specification, the firmware is not required to configure
> > > the BAR register other than for boot and console devices. This means an
> > > Operating System (or the hypervisor in our case) may have to configure 
> > > some
> > > devices.
> > > 
> > > In order to configure the BAR register, Xen would need to know where are 
> > > the
> > > PCI resources. On ACPI they can be found in ASL, however Xen is not able 
> > > to
> > > parse it. In the case of Device Tree with can retrieve the PCI resources
> > > using the property "ranges".
> > > 
> > > I can see a couple of solutions:
> > >   1# Rely on DOM0 to do the PCI configuration. This means that DOM0 should
> > > see all the PCI devices and therefore will not be possible to hide from 
> > > DOM0
> > > if we know at boot a device will be used by a guest (i.e something similar
> > > to pciback.hide but directly handled in Xen).
> > 
> > .. this as for SR-IOV devices you need the drivers to kick the hardware
> > to generate the new bus addresses. And those (along with the BAR regions) 
> > are
> > not visible in ACPI (they are constructued dynamically).
> 
> There's already code in Xen [0] to find out the size of the BARs of SR-IOV
> devices, but I'm not sure what's the intended usage of that, does it need to
> happen _after_ the driver in Dom0 has done whatever magic for this to work?

Yes. This is called via the PHYSDEVOP_pci_device_add hypercall when
the device driver in dom0 has finished "creating" the VF. See drivers/xen/pci.c
> 
> Roger.
> 
> [0] 
> http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/drivers/passthrough/pci.c;h=beddd4270161b9b00b792124a770bbafe398939a;hb=HEAD#l639

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

Re: [Xen-devel] [PATCH][XTF] allow x{g, s}etbv() to also be used in 32-bit code

[Andrew Cooper]

On 09/03/17 10:22, Jan Beulich wrote:
> Their 64-bit register constraints prevented this so far.
>
> Signed-off-by: Jan Beulich 

Ah - I already noticed and fixed this in
http://xenbits.xen.org/gitweb/?p=xtf.git;a=commitdiff;h=07f29b74020fa3b3f4fc2209e620e71a838062b4

In fact, the patch is identical it seems.

Clang appears to interpret the static inlines even if they are not
instantiated in code.

~Andrew

>
> --- a/include/arch/x86/lib.h
> +++ b/include/arch/x86/lib.h
> @@ -398,18 +398,18 @@ static inline unsigned int str(void)
>  
>  static inline uint64_t xgetbv(uint32_t index)
>  {
> -uint32_t feat_lo;
> -uint64_t feat_hi;
> +uint32_t feat_lo, feat_hi;
>  
>  asm volatile ("xgetbv" : "=a" (feat_lo), "=d" (feat_hi)
> :  "c" (index) );
>  
> -return feat_lo | (feat_hi << 32);
> +return feat_lo | ((uint64_t)feat_hi << 32);
>  }
>  
>  static inline void xsetbv(uint32_t index, uint64_t value)
>  {
> -asm volatile ("xsetbv" :: "a" ((uint32_t)value), "d" (value >> 32),
> +asm volatile ("xsetbv" :: "a" ((uint32_t)value),
> +  "d" ((uint32_t)(value >> 32)),
>"c" (index) );
>  }
>  
>
>
>


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

Re: [Xen-devel] [PATCH] xen: credit2: remove undefined static function __dump_execstate().

[Jan Beulich]

>>> On 09.03.17 at 11:36,  wrote:
> On Thu, 2017-03-09 at 03:09 -0700, Jan Beulich wrote:
>> > > > On 09.03.17 at 10:54,  wrote:
>> > 
>> > --- a/xen/common/sched_credit2.c
>> > +++ b/xen/common/sched_credit2.c
>> > @@ -2437,8 +2437,6 @@ csched2_runtime(const struct scheduler *ops,
>> > int cpu,
>> >  return time;
>> >  }
>> >  
>> > -void __dump_execstate(void *unused);
>> 
>> All fine, except the function wasn't static (or else the compiler
>> would
>> have warned about there not being a definition), so perhaps the
>> subject wants to say "undefined function declaration" or some such.
>> 
> Right, of course it's not... sorry. What I was aiming was to somehow
> reinforce the fact that it's only present in this file, but that's not
> really necessary, and 'static' was very wrong a word for that.
> 
> I'd be fine with a subject line like:
> 
> "xen: credit: remove undefined declaration of __dump_execstate()"

Fine with me (with s/credit/credit2/), and I'm fine without resend, but
in the end it's George to judge (unless he gives his ack, deferring to me
to adjust and apply).

Jan


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

Re: [Xen-devel] [PATCH v2 5/6] x86_emulate: Remove dependency on __LINE__ for release builds

[Jan Beulich]

>>> On 08.03.17 at 18:46,  wrote:
> @@ -791,9 +807,7 @@ do{ asm volatile (
>   \
>   [stub] "rm" (stub.func) ); \
>  if ( unlikely(~res_.raw) )  \
>  {   \
> -gprintk(XENLOG_WARNING, \
> -"exception %u (ec=%04x) in emulation stub (line %u)\n", \
> -res_.fields.trapnr, res_.fields.ec, __LINE__);  \
> +invoke_stub_exception(res_.fields.trapnr, res_.fields.ec);  \

This presumably is the worst of the changes in this series, as
explained in reply to the overview mail: The text address is going
to point into a huge function, and reconstruction of the source
line is going to be rather cumbersome in case line2addr fails
(which afaik it is not unknown for).

Jan


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

Re: [Xen-devel] [PATCH v2 4/6] iommu: Remove dependency on __LINE__ for release builds

[Jan Beulich]

>>> On 08.03.17 at 18:46,  wrote:

When seeing the title I wondered by I didn't get Cc-ed. Perhaps the
prefix would better have been VT-d: ?

> --- a/xen/drivers/passthrough/vtd/dmar.h
> +++ b/xen/drivers/passthrough/vtd/dmar.h
> @@ -108,6 +108,19 @@ struct acpi_atsr_unit 
> *acpi_find_matched_atsr_unit(const struct pci_dev *);
>  
>  #define DMAR_OPERATION_TIMEOUT MILLISECS(1000)
>  
> +#if defined(NDEBUG) && defined(CONFIG_LIVEPATCH)
> +#define iommu_wait_op_panic()  \
> +do {   \
> +panic("%pS: DMAR hardware is malfunctional", current_text_addr()); \
> +} while (0)
> +#else
> +#define iommu_wait_op_panic()  \
> +do {   \
> +panic("%s:%d:%s: DMAR hardware is malfunctional",  \
> +  __FILE__, __LINE__, __func__);   \

If you touch this already, may I suggest eliminating the redundancy
here: Either file or function name should suffice to uniquely identify
the origin.

Jan


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

[Xen-devel] [libvirt test] 106562: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

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

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

version targeted for testing:
 libvirt  b2e5de96c7f3347c2463ca96932e9f4719be2a45
baseline version:
 libvirt  9d60ea31dd1233756128768cf77b21b7c647d85d

Last test of basis   106543  2017-03-08 04:20:51 Z1 days
Testing same since   106562  2017-03-09 04:21:54 Z0 days1 attempts


People who touched revisions under test:
  Cole Robinson 
  John Ferlan 
  Michal Privoznik 
  Pavel Hrdina 
  Philipp Hahn 

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



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

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

Explanation of these reports, and of osstest in general, is at

Re: [Xen-devel] [PATCH] xen: credit2: remove undefined static function __dump_execstate().

[Dario Faggioli]

On Thu, 2017-03-09 at 03:09 -0700, Jan Beulich wrote:
> > > > On 09.03.17 at 10:54,  wrote:
> > 
> > --- a/xen/common/sched_credit2.c
> > +++ b/xen/common/sched_credit2.c
> > @@ -2437,8 +2437,6 @@ csched2_runtime(const struct scheduler *ops,
> > int cpu,
> >  return time;
> >  }
> >  
> > -void __dump_execstate(void *unused);
> 
> All fine, except the function wasn't static (or else the compiler
> would
> have warned about there not being a definition), so perhaps the
> subject wants to say "undefined function declaration" or some such.
> 
Right, of course it's not... sorry. What I was aiming was to somehow
reinforce the fact that it's only present in this file, but that's not
really necessary, and 'static' was very wrong a word for that.

I'd be fine with a subject line like:

"xen: credit: remove undefined declaration of __dump_execstate()"

Let me know if you or George prefer that I resend, or to adjust this
upon commit. Or just ignore this mail, and if I don't hear anything for
 a while, I will just resend. :-)

Thanks,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)

signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 0/6] Remove dependency on __LINE__

[Jan Beulich]

>>> On 08.03.17 at 18:46,  wrote:
> Sorry for the long delay since the first version of this series
> (previously called "Make building xSplice patches easier").  Here is a
> set of changes that remove the use of __LINE__ when building with NDEBUG
> and LivePatch enabled.  Tested to boot on x86.  Compile-tested on arm.

What I'm missing here is an evaluation of possible alternatives, as
converting from __LINE__ to code addresses implies an extra step
when wanting to look up the place where a problem occurred,
which I generally consider undesirable. For example, I had briefly
discussed with Andrew the addition of #line directives, but iirc he
had indicated some issue with that. Furthermore there is the
option (at least for some of the more simple patches) of squeezing
more than one statement on a single line, perhaps just for patch
creation. And I guess one can think of more.

Jan


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