[Xen-devel] [qemu-upstream-4.5-testing test] 105959: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl   17 guest-localmigrate/x10   fail REGR. vs. 102714
 test-amd64-i386-freebsd10-amd64 16 guest-localmigrate/x10 fail REGR. vs. 102714

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail like 102684
 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail like 102699
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 102705
 test-amd64-amd64-xl-rtds  6 xen-boot fail  like 102714

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   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-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   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-libvirt-raw 10 guest-start  fail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  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-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-vhd  10 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

version targeted for testing:
 qemuuad0d3c66fa90fabc988311fd654f79c3131a4027
baseline version:
 qemuu37a460ca696381bb14dfbf012d7a062c7c05c324

Last test of basis   102714  2016-11-29 16:12:07 Z   84 days
Testing same since   105959  2017-02-21 19:50:46 Z0 days1 attempts


People who touched revisions under test:
  Bruce Rogers 
  Gerd Hoffmann 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   fail
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-amd64-xl-pvh-amd  fail
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  fail
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-armhf-armhf-xl-arndale  pass
 test-amd64-amd64-xl-credit2  pass
 test-armhf-armhf-xl-credit2  pass
 test-armhf-armhf-xl-cubietruck   pass
 test-amd64-i386-freebsd10-i386   pass
 test-amd64-amd64-qemuu-nested-intel  pass
 test-amd64-amd64-xl-pvh-intelfail  

Re: [Xen-devel] [PATCH 06/10] x86/cpuid: Handle leaf 0x6 in guest_cpuid()

[Andrew Cooper]

On 22/02/17 07:31, Jan Beulich wrote:
 On 21.02.17 at 18:40,  wrote:
>> On 21/02/17 17:25, Jan Beulich wrote:
>> On 20.02.17 at 12:00,  wrote:
 The thermal/performance leaf was previously hidden from HVM guests, but 
>> fully
 visible to PV guests.  Most of the leaf refers to MSR availability, and 
>> there
 is nothing an unprivileged PV guest can do with the information, so hide 
 the
 leaf entirely.

 The PV MSR handling logic as minimal support for some thermal/perf 
 operations
>>> ... has ...
>>>
 from the hardware domain, so leak through the implemented subset of 
 features.
>>> Does it make sense to continue to special case PV hwdom here?
>> Being able to play with these MSRs will be actively wrong for HVM
>> context.  It is already fairly wrong for PV context, as nothing prevents
>> you being rescheduled across pcpus while in the middle of a read/write
>> cycle on the MSRs.
> So the MSRs in question are, afaics
> - MSR_IA32_MPERF, MSR_IA32_APERF, MSR_IA32_PERF_CTL (all
>   of which are is_cpufreq_controller() dependent)
> - MSR_IA32_THERM_CONTROL, MSR_IA32_ENERGY_PERF_BIAS
>   (both of which are is_pinned_vcpu() dependent)
> For the latter your argument doesn't apply. For the former, I've
> been wondering for a while whether we shouldn't do away with
> "cpufreq=dom0-kernel".

Hmm.  All good points.  If I can get away without leaking any of this,
that would be ideal.  (Lets see what Linux thinks of such a setup.)

~Andrew

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

Re: [Xen-devel] [PATCH v2 1/3] x86/vmx: introduce vmx_find_msr()

[Sergey Dyasli]

On Tue, 2017-02-21 at 09:29 +, Tian, Kevin wrote:
> > From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
> > Sent: Friday, February 17, 2017 11:43 PM
> > 
> > Modify vmx_add_msr() to use a variation of insertion sort algorithm:
> > find a place for the new entry and shift all subsequent elements before
> > insertion.
> > 
> > The new vmx_find_msr() exploits the fact that MSR list is now sorted
> > and reuses the existing code for binary search.
> > 
> > Signed-off-by: Sergey Dyasli 
> > ---
> > v1 --> v2:
> > - qsort (heap sort) is replaced with a variant of insertion sort
> > - both host and guest MSR lists are now kept sorted
> > - vmx_find_guest_msr() is replaced with more generic vmx_find_msr()
> > 
> >  xen/arch/x86/hvm/vmx/vmcs.c| 45
> > --
> >  xen/include/asm-x86/hvm/vmx/vmcs.h |  1 +
> >  2 files changed, 44 insertions(+), 2 deletions(-)
> > 
> > diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
> > index 454d444..49587d6 100644
> > --- a/xen/arch/x86/hvm/vmx/vmcs.c
> > +++ b/xen/arch/x86/hvm/vmx/vmcs.c
> > @@ -1307,6 +1307,44 @@ static int construct_vmcs(struct vcpu *v)
> >  return 0;
> >  }
> > 
> > +static int vmx_msr_entry_key_cmp(const void *key, const void *elt)
> 
> what is 'elt' short for?

The prototype was taken directly from bsearch():

int (*cmp)(const void *key, const void *elt)

I believe that elt stands for element.

> 
> > +{
> > +const u32 *msr = key;
> > +const struct vmx_msr_entry *entry = elt;
> > +
> > +if ( *msr > entry->index )
> > +return 1;
> > +if ( *msr < entry->index )
> > +return -1;
> > +
> > +return 0;
> > +}
> > +
> > +struct vmx_msr_entry *vmx_find_msr(u32 msr, int type)
> > +{
> > +struct vcpu *curr = current;
> > +unsigned int msr_count;
> > +struct vmx_msr_entry *msr_area;
> > +
> > +if ( type == VMX_GUEST_MSR )
> > +{
> > +msr_count = curr->arch.hvm_vmx.msr_count;
> > +msr_area = curr->arch.hvm_vmx.msr_area;
> > +}
> > +else
> > +{
> > +ASSERT(type == VMX_HOST_MSR);
> > +msr_count = curr->arch.hvm_vmx.host_msr_count;
> > +msr_area = curr->arch.hvm_vmx.host_msr_area;
> > +}
> > +
> > +if ( msr_area == NULL )
> > +return NULL;
> > +
> > +return bsearch(&msr, msr_area, msr_count, sizeof(struct vmx_msr_entry),
> > +   vmx_msr_entry_key_cmp);
> > +}
> > +
> >  int vmx_read_guest_msr(u32 msr, u64 *val)
> >  {
> >  struct vcpu *curr = current;
> > @@ -1375,14 +1413,17 @@ int vmx_add_msr(u32 msr, int type)
> >  __vmwrite(VM_EXIT_MSR_LOAD_ADDR, virt_to_maddr(*msr_area));
> >  }
> > 
> > -for ( idx = 0; idx < *msr_count; idx++ )
> > +for ( idx = 0; (*msr_area)[idx].index <= msr && idx < *msr_count; 
> > idx++ )
> 
> risk of out-of-boundary access. 

How exactly out-of-bounds access is possible? The original condition

idx < *msr_count

Is still being checked on each loop iteration.

> 
> >  if ( (*msr_area)[idx].index == msr )
> >  return 0;
> > 
> >  if ( *msr_count == (PAGE_SIZE / sizeof(struct vmx_msr_entry)) )
> >  return -ENOSPC;
> > 
> > -msr_area_elem = *msr_area + *msr_count;
> > +memmove(*msr_area + idx + 1, *msr_area + idx,
> > +sizeof(*msr_area_elem) * (*msr_count - idx));
> > +
> > +msr_area_elem = *msr_area + idx;
> >  msr_area_elem->index = msr;
> >  msr_area_elem->mbz = 0;
> > 
> > diff --git a/xen/include/asm-x86/hvm/vmx/vmcs.h
> > b/xen/include/asm-x86/hvm/vmx/vmcs.h
> > index c30aab6..903af51 100644
> > --- a/xen/include/asm-x86/hvm/vmx/vmcs.h
> > +++ b/xen/include/asm-x86/hvm/vmx/vmcs.h
> > @@ -529,6 +529,7 @@ void vmx_disable_intercept_for_msr(struct vcpu *v, u32 
> > msr, int
> > type);
> >  void vmx_enable_intercept_for_msr(struct vcpu *v, u32 msr, int type);
> >  int vmx_read_guest_msr(u32 msr, u64 *val);
> >  int vmx_write_guest_msr(u32 msr, u64 val);
> > +struct vmx_msr_entry *vmx_find_msr(u32 msr, int type);
> >  int vmx_add_msr(u32 msr, int type);
> >  void vmx_vmcs_switch(paddr_t from, paddr_t to);
> >  void vmx_set_eoi_exit_bitmap(struct vcpu *v, u8 vector);
> > --
> > 2.9.3
> 
> 
-- 
Thanks,
Sergey
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 1/3] x86/vmx: introduce vmx_find_msr()

[Tian, Kevin]

> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
> Sent: Wednesday, February 22, 2017 4:38 PM
> 
> > >
> > > -for ( idx = 0; idx < *msr_count; idx++ )
> > > +for ( idx = 0; (*msr_area)[idx].index <= msr && idx < *msr_count; 
> > > idx++ )
> >
> > risk of out-of-boundary access.
> 
> How exactly out-of-bounds access is possible? The original condition
> 
> idx < *msr_count
> 
> Is still being checked on each loop iteration.
> 

Isn't "(*msr_area[idx]).index <= msr" checked before "idx < *msr_count"?

So if idx==*msr_count, you first hit an out-of-boundary access...

I think we should change the condition order here.

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

Re: [Xen-devel] [PATCH v2 1/3] x86/vmx: introduce vmx_find_msr()

[Sergey Dyasli]

On Wed, 2017-02-22 at 08:40 +, Tian, Kevin wrote:
> > From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
> > Sent: Wednesday, February 22, 2017 4:38 PM
> > 
> > > > 
> > > > -for ( idx = 0; idx < *msr_count; idx++ )
> > > > +for ( idx = 0; (*msr_area)[idx].index <= msr && idx < *msr_count; 
> > > > idx++ )
> > > 
> > > risk of out-of-boundary access.
> > 
> > How exactly out-of-bounds access is possible? The original condition
> > 
> > idx < *msr_count
> > 
> > Is still being checked on each loop iteration.
> > 
> 
> Isn't "(*msr_area[idx]).index <= msr" checked before "idx < *msr_count"?
> 
> So if idx==*msr_count, you first hit an out-of-boundary access...
> 
> I think we should change the condition order here.
> 

You are right. I will fix this in v3.

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

Re: [Xen-devel] [xen-4.7-testing test] 105948: regressions - FAIL

[Jan Beulich]

>>> On 22.02.17 at 01:02,  wrote:
> On 21/02/2017 23:45, osstest service owner wrote:
>> flight 105948 xen-4.7-testing real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/105948/ 
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> including tests which could not be run:
>>  test-amd64-amd64-xl-credit2  17 guest-localmigrate/x10   fail REGR. vs. 
>> 105855
> 
> From
> http://logs.test-lab.xenproject.org/osstest/logs/105948/test-amd64-amd64-xl- 
> credit2/serial-nobling0.log
> around Feb 21 20:32:01.481626
> 
> (XEN) csched2_vcpu_insert: Inserting d5v0
> (XEN) csched2_vcpu_insert: Inserting d5v1
> (XEN) csched2_vcpu_insert: Inserting d5v2
> (XEN) csched2_vcpu_insert: Inserting d5v3
> (XEN) Assertion 'd->cpupool != NULL' failed at
> ...5948.build-amd64/xen/xen/include/xen/sched-if.h:200
> (XEN) [ Xen-4.7.2-pre  x86_64  debug=y  Not tainted ]
> (XEN) CPU:14
> (XEN) RIP:e008:[]
> sched_credit2.c#vcpu_is_migrateable+0x22/0x9a
> (XEN) RFLAGS: 00010046   CONTEXT: hypervisor
> (XEN) rax: 8304573bc000   rbx: 83047f114f10   rcx: 83007baca000
> (XEN) rdx:    rsi: 83023fed0458   rdi: 83047f114f10
> (XEN) rbp: 830473fffd60   rsp: 830473fffd40   r8:  14a138bf
> (XEN) r9:  14a538bf   r10: 00021e54   r11: 0f0f0f0f0f0f0f0f
> (XEN) r12: 83047f114190   r13: 000e   r14: 82d0802e66c0
> (XEN) r15: 83023fed   cr0: 80050033   cr4: 003526e4
> (XEN) cr3: 000457499000   cr2: 880002810288
> (XEN) ds:    es:    fs:    gs:    ss: e010   cs: e008
> (XEN) Xen code around 
> (sched_credit2.c#vcpu_is_migrateable+0x22/0x9a):
> (XEN)  8b 50 68 48 85 d2 75 02 <0f> 0b 49 89 f4 48 89 fb 48 8d 05 81 52
> 21 00 48
> (XEN) Xen stack trace from rsp=830473fffd40:
> (XEN)0006 83047f114f10 83047f114190 83023fed0498
> (XEN)830473fffe20 82d080129763 830473fffde0 82d0802e66c0
> (XEN)83023fed 83023fed 8304000e 8304000e
> (XEN)0007000e 00528d5c4e92 830473fffdc8 830473fffe68
> (XEN)82d080130110 02a5a4fa  
> (XEN)83023fed0960 83023fed0458 0002 8300679fc000
> (XEN)82d08033c140 00528d5c4e92 83023fed0964 000e
> (XEN)830473fffeb0 82d08012c17e a6671e870002 83023ff70160
> (XEN)000e00fffe60 83023ff70140 830473fffe60 82d0801301a1
> (XEN)830473fffeb0 82d0801330ad 830473fffef0 82d0801bb4a2
> (XEN)0010679fc000 82d080313180 82d080312a80 
> (XEN)830473ff 8304677f2000 830473fffee0 82d08012f8bd
> (XEN)830473ff 83007bad  83023fec2000
> (XEN)830473fffef0 82d08012f912 83047310 82d080164b17
> (XEN)82d08012f912 8300679fc000 830473fffdd8 
> (XEN)81c01fd8 81c01fd8  81c01e68
> (XEN) 0246 00528d4bace3 
> (XEN)  810013aa 81c319a0
> (XEN)deadbeef deadbeef 0100 810013aa
> (XEN)e033 0246 81c01e50 e02b
> (XEN) Xen call trace:
> (XEN)[] sched_credit2.c#vcpu_is_migrateable+0x22/0x9a
> (XEN)[] sched_credit2.c#csched2_schedule+0x823/0xb4e
> (XEN)[] schedule.c#schedule+0x108/0x609
> (XEN)[] softirq.c#__do_softirq+0x7f/0x8a
> (XEN)[] do_softirq+0x13/0x15
> (XEN)[] domain.c#idle_loop+0x55/0x62
> (XEN)
> (XEN)
> (XEN) 
> (XEN) Panic on CPU 14:
> (XEN) Assertion 'd->cpupool != NULL' failed at
> ...5948.build-amd64/xen/xen/include/xen/sched-if.h:200
> (XEN) 
> (XEN)
> (XEN) Manual reset required ('noreboot' specified)
> 
> I am guessing the most recent credit2 backports weren't quite so safe?

Well, there was only one in the batch under test (and that is what
adds the cpupool_domain_cpumask() causing the ASSERT() above
to trigger). However, comparing with the staging version of the file
(which is heavily different), the immediate code involved here isn't
all that different, so I wonder whether (a) this is a problem on
staging too or (b) we're missing another backport. Dario?

Jan

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

Re: [Xen-devel] [PATCH] iommu: Elaborate the usage of RMRR specification on the command line.

[Jan Beulich]

>>> On 21.02.17 at 21:42,  wrote:
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -1406,6 +1406,15 @@ If segment of the first device is not specified, 
> segment zero will be used.
>  If other segments are not specified, first device segment will be used.
>  If a segment is specified for other than the first device and it does not 
> match
>  the one specified for the first one, an error will be reported.
> +
> +'start' and 'end' values are page numbers (not full physical addresses).
> +If the values are not preceded by "0x", they are treated as decimal.

Actually I think we should fix the code. I can't see how decimal
numbers can be useful here, and it is actively confusing with ...

> +Usage example: If there are two devices 0:0:1d.0 and 0:0:1a.0 that require
> +pages 0xd5d45 and 0xd5d46 to be reserved respectively, use:
> +
> +rmrr=0xd5d45=0:0:1d.0;0xd5d46=0:0:1a.0

... the PCI device being specified without 0x prefixes.

Also can one of the two parts of the example be a range, please?

Jan


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

Re: [Xen-devel] [PATCH v8 4/7] VT-d: Use one function to update both remapped and posted IRTE

[Chao Gao]

On Tue, Nov 22, 2016 at 05:58:56PM +0800, Jan Beulich wrote:
 On 18.11.16 at 02:57,  wrote:
>> @@ -597,31 +598,50 @@ static int msi_msg_to_remap_entry(
>
>Considering you basically re-do most of the function, I think there's
>some more adjustment necessary (or at least very desirable) here.
>
>>
>>  memcpy(&new_ire, iremap_entry, sizeof(struct iremap_entry));
>>
>> -/* Set interrupt remapping table entry */
>> -new_ire.remap.fpd = 0;
>> -new_ire.remap.dm = (msg->address_lo >> MSI_ADDR_DESTMODE_SHIFT) & 0x1;
>> -new_ire.remap.tm = (msg->data >> MSI_DATA_TRIGGER_SHIFT) & 0x1;
>> -new_ire.remap.dlm = (msg->data >> MSI_DATA_DELIVERY_MODE_SHIFT) & 0x1;
>> -/* Hardware require RH = 1 for LPR delivery mode */
>> -new_ire.remap.rh = (new_ire.remap.dlm == dest_LowestPrio);
>> -new_ire.remap.avail = 0;
>> -new_ire.remap.res_1 = 0;
>> -new_ire.remap.vector = (msg->data >> MSI_DATA_VECTOR_SHIFT) &
>> -MSI_DATA_VECTOR_MASK;
>> -new_ire.remap.res_2 = 0;
>> -if ( x2apic_enabled )
>> -new_ire.remap.dst = msg->dest32;
>> +if ( !pi_desc )
>> +{
>> +/* Set interrupt remapping table entry */
>> +new_ire.remap.fpd = 0;
>> +new_ire.remap.dm = (msg->address_lo >> MSI_ADDR_DESTMODE_SHIFT) & 
>> 0x1;
>> +new_ire.remap.tm = (msg->data >> MSI_DATA_TRIGGER_SHIFT) & 0x1;
>
>These two "& 0x1" seem unnecessary, as the fields are 1 bit only
>anyway.
>

Ok, will remove them.

>> +new_ire.remap.dlm = (msg->data >> MSI_DATA_DELIVERY_MODE_SHIFT) & 
>> 0x1;
>
>This masking, however, has always been puzzling me: dlm is a 3 bit
>field, and the MSI message field is a 3-bit one too. Hence the
>masking should also be dropped here - if the message field is wrong
>(i.e. holding an unsupported value), there's no good reason to try
>to compensate for it here. If at all the function should refuse to do
>the requested translation.
>
>> +/* Hardware require RH = 1 for LPR delivery mode */
>> +new_ire.remap.rh = (new_ire.remap.dlm == dest_LowestPrio);
>> +new_ire.remap.avail = 0;
>> +new_ire.remap.res_1 = 0;
>> +new_ire.remap.vector = (msg->data >> MSI_DATA_VECTOR_SHIFT) &
>> +MSI_DATA_VECTOR_MASK;
>> +new_ire.remap.res_2 = 0;
>> +if ( x2apic_enabled )
>> +new_ire.remap.dst = msg->dest32;
>> +else
>> +new_ire.remap.dst = ((msg->address_lo >> MSI_ADDR_DEST_ID_SHIFT)
>> + & 0xff) << 8;
>> +
>> +new_ire.remap.res_3 = 0;
>> +new_ire.remap.res_4 = 0;
>> +new_ire.remap.p = 1;/* finally, set present bit */
>
>I don't understand this comment. The order of operations does not
>matter at all, and in fact you now set p before being done with all
>other fields. Please drop such misleading comments, or make them
>useful/correct.

Yes, The order does not matter. I will drop this comment.

>
>Also, the only field you don't explicitly set here is .im. Why?
>
>> +}
>>  else
>> -new_ire.remap.dst = ((msg->address_lo >> MSI_ADDR_DEST_ID_SHIFT)
>> - & 0xff) << 8;
>> +{
>> +new_ire.post.fpd = 0;
>> +new_ire.post.res_1 = 0;
>> +new_ire.post.res_2 = 0;
>> +new_ire.post.urg = 0;
>> +new_ire.post.im = 1;
>> +new_ire.post.vector = gvec;
>> +new_ire.post.res_3 = 0;
>> +new_ire.post.res_4 = 0;
>> +new_ire.post.res_5 = 0;
>> +new_ire.post.pda_l = virt_to_maddr(pi_desc) >> (32 - PDA_LOW_BIT);
>> +new_ire.post.pda_h = virt_to_maddr(pi_desc) >> 32;
>> +new_ire.post.p = 1;/* finally, set present bit */
>> +}
>
>Along the lines of the comment above, you don't fill avail here. Why?
>
>Taking both together, I don't see why - after adding said initialization -
>new_ire needs to start out as a copy of the live IRTE. Instead you
>could memset() the whole structure to zero, or simply give it an empty
>initializer (saving you from initializing all the reserved fields, plus some
>more).
>

Yes, it is really confused. Maybe because this field is available to software 
in posting
format IRTE. We can reserve the avail field through introducing a flag to
distinguish initialization from update. We also can clear the avail field every
time if we don't use it right now, leaving the problem to others who want use
the avail field.  Do you think which is better?

>And of course, along the lines of ...
>
>>  if ( pdev )
>>  set_msi_source_id(pdev, &new_ire);
>>  else
>>  set_hpet_source_id(msi_desc->hpet_id, &new_ire);
>
>... this, I see little reason for common fields to be initialized separately
>on each path. According to the code above that's only p (leaving
>aside fields which get zeroed), but anyway. Perhaps there should
>even be a common sub-structure of the union ...

I can add a patch in this series to do this.

Re: [Xen-devel] [PATCH v8 4/7] VT-d: Use one function to update both remapped and posted IRTE

[Jan Beulich]

>>> On 22.02.17 at 02:53,  wrote:
> On Tue, Nov 22, 2016 at 05:58:56PM +0800, Jan Beulich wrote:
> On 18.11.16 at 02:57,  wrote:
>>>  else
>>> -new_ire.remap.dst = ((msg->address_lo >> MSI_ADDR_DEST_ID_SHIFT)
>>> - & 0xff) << 8;
>>> +{
>>> +new_ire.post.fpd = 0;
>>> +new_ire.post.res_1 = 0;
>>> +new_ire.post.res_2 = 0;
>>> +new_ire.post.urg = 0;
>>> +new_ire.post.im = 1;
>>> +new_ire.post.vector = gvec;
>>> +new_ire.post.res_3 = 0;
>>> +new_ire.post.res_4 = 0;
>>> +new_ire.post.res_5 = 0;
>>> +new_ire.post.pda_l = virt_to_maddr(pi_desc) >> (32 - PDA_LOW_BIT);
>>> +new_ire.post.pda_h = virt_to_maddr(pi_desc) >> 32;
>>> +new_ire.post.p = 1;/* finally, set present bit */
>>> +}
>>
>>Along the lines of the comment above, you don't fill avail here. Why?
>>
>>Taking both together, I don't see why - after adding said initialization -
>>new_ire needs to start out as a copy of the live IRTE. Instead you
>>could memset() the whole structure to zero, or simply give it an empty
>>initializer (saving you from initializing all the reserved fields, plus some
>>more).
>>
> 
> Yes, it is really confused. Maybe because this field is available to software 
> in posting
> format IRTE. We can reserve the avail field through introducing a flag to
> distinguish initialization from update. We also can clear the avail field 
> every
> time if we don't use it right now, leaving the problem to others who want use
> the avail field.  Do you think which is better?

As its unused, clear it every time. We simply don't know how a
potential use would want it set during update.

>>> @@ -637,7 +657,23 @@ static int msi_msg_to_remap_entry(
>>>  remap_rte->address_hi = 0;
>>>  remap_rte->data = index - i;
>>>
>>> -memcpy(iremap_entry, &new_ire, sizeof(struct iremap_entry));
>>> +if ( !pi_desc )
>>> +memcpy(iremap_entry, &new_ire, sizeof(struct iremap_entry));
>>> +else
>>> +{
>>> +__uint128_t ret;
>>> +
>>> +old_ire = *iremap_entry;
>>> +ret = cmpxchg16b(iremap_entry, &old_ire, &new_ire);
>>> +
>>> +/*
>>> + * In the above, we use cmpxchg16 to atomically update the 128-bit 
>>> IRTE,
>>> + * and the hardware cannot update the IRTE behind us, so the 
>>> return value
>>> + * of cmpxchg16 should be the same as old_ire. This ASSERT 
>>> validate it.
>>> + */
>>> +ASSERT(ret == old_ire.val);
>>> +}
>>
>>Could you remind me again please why posted format updates need
>>to use cmpxchg16b, but remapped format ones don't? (As a aside,
>>with the code structure as you have it you should move the old_irte
>>declaration here, or omit it altogether, as you could as well pass
>>*iremap_entry directly afaict.)
> 
> Before feng left, I have asked him about this question. He told me that
> the PDA field of posted format IRTE comprises of two parts:
> Posted Descritor Address High[127:96] and Low [63:38]. If we want to update
> PDA field, do it atomically or disable-update-enable. He also said, it had
> been confirmed that cmpxchg16b was supported on all intel platform with VT-d 
> PI.
> If we assume that updates to remapped format IRTE only is to update either
> 64 bit or high 64 bit (except initialition), two 64bit memory write operations
> is enough. 

Two 64-bit memory write operations? Where do you see them? I
only see memcpy(), which for the purposes of the code here is
supposed to be a black box.

>>> @@ -668,7 +704,8 @@ int msi_msg_write_remap_rte(
>>>
>>>  drhd = pdev ? acpi_find_matched_drhd_unit(pdev)
>>>  : hpet_to_drhd(msi_desc->hpet_id);
>>> -return drhd ? msi_msg_to_remap_entry(drhd->iommu, pdev, msi_desc, msg)
>>> +return drhd ? msi_msg_to_remap_entry(drhd->iommu, pdev,
>>> + msi_desc, msg, NULL, 0)
>>
>>Is this unconditional passing of NULL here really correct?
> 
> Since two parameters are added to this function, we should think about what
> the function does again. the last 2 parameters are optional.
> 
> If they are not present, just means a physical device driver changes its msi
> message. So it notifies iommu to do some changes to IRTE accordingly (the 
> driver doesn't
> know the format of the live IRTE). This is the case above.
> 
> If they are present, it means the msi should be delivered to the vcpu with the
> vector num. To achieve that, the function replaces the old IRTE with a new
> posted format IRTE.

I don't see how this answers my question. In fact it feels like you,
just like Feng, are making assumptions on the conditions under
which the function here is being called _at present_. You should,
however, make the function work correctly for all possible uses,
or add ASSERT()s to clearly expose issues with potential new,
future callers.

>>> @@ -992,35 +986,11 @@ int pi_update_irte(const struct vcpu *v, cons

Re: [Xen-devel] [PATCH 07/10] x86/cpuid: Handle leaf 0xa in guest_cpuid()

[Jan Beulich]

>>> On 20.02.17 at 12:00,  wrote:
> Leaf 0xa is reserved by AMD, and only exposed to Intel guests when vPMU is
> enabled.  Leave the logic as-was, ready to be cleaned up when further
> toolstack infrastructure is in place.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 



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

Re: [Xen-devel] [PATCH 06/10] x86/cpuid: Handle leaf 0x6 in guest_cpuid()

[Andrew Cooper]

On 22/02/17 08:23, Andrew Cooper wrote:
> On 22/02/17 07:31, Jan Beulich wrote:
> On 21.02.17 at 18:40,  wrote:
>>> On 21/02/17 17:25, Jan Beulich wrote:
>>> On 20.02.17 at 12:00,  wrote:
> The thermal/performance leaf was previously hidden from HVM guests, but 
>>> fully
> visible to PV guests.  Most of the leaf refers to MSR availability, and 
>>> there
> is nothing an unprivileged PV guest can do with the information, so hide 
> the
> leaf entirely.
>
> The PV MSR handling logic as minimal support for some thermal/perf 
> operations
 ... has ...

> from the hardware domain, so leak through the implemented subset of 
> features.
 Does it make sense to continue to special case PV hwdom here?
>>> Being able to play with these MSRs will be actively wrong for HVM
>>> context.  It is already fairly wrong for PV context, as nothing prevents
>>> you being rescheduled across pcpus while in the middle of a read/write
>>> cycle on the MSRs.
>> So the MSRs in question are, afaics
>> - MSR_IA32_MPERF, MSR_IA32_APERF, MSR_IA32_PERF_CTL (all
>>   of which are is_cpufreq_controller() dependent)
>> - MSR_IA32_THERM_CONTROL, MSR_IA32_ENERGY_PERF_BIAS
>>   (both of which are is_pinned_vcpu() dependent)
>> For the latter your argument doesn't apply. For the former, I've
>> been wondering for a while whether we shouldn't do away with
>> "cpufreq=dom0-kernel".
> Hmm.  All good points.  If I can get away without leaking any of this,
> that would be ideal.  (Lets see what Linux thinks of such a setup.)

Linux seems fine without any of this leakage.  I have checked and C/P
state information is still propagated up to Xen.  I will drop the entire
dynamic adjustment.

~Andrew

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

Re: [Xen-devel] [PATCH 08/10] x86/cpuid: Handle leaf 0xb in guest_cpuid()

[Jan Beulich]

>>> On 20.02.17 at 12:00,  wrote:
> Leaf 0xb is reserved by AMD, and uniformly hidden from guests by the toolstack
> logic and hypervisor PV logic.
> 
> The previous dynamic logic filled in the x2APIC ID for all HVM guests.  This
> is modified to respect the entire leaf being reserved by AMD, but is altered
> to include PV Intel guests, so they get more sensible values in their emulated
> and faulted view of CPUID.

Don't we expose x2APIC to HVM guests even on AMD systems? In
which case we surely will want to also expose the x2APIC ID.

> @@ -959,6 +950,14 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf,
>  }
>  break;
>  
> +case 0xb:
> +if ( p->x86_vendor == X86_VENDOR_INTEL )
> +{
> +/* Fix the x2APIC identifier. */
> +res->d = v->vcpu_id * 2;
> +}
> +break;

Irrespective of the comment above, wouldn't the if() here better
look at the x2APIC feature flag of the domain?

Jan


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

Re: [Xen-devel] [RFC PATCH v1 01/21] ARM: NUMA: Add existing ARM numa code under CONFIG_NUMA

[Vijay Kilari]

On Mon, Feb 20, 2017 at 5:09 PM, Julien Grall  wrote:
> Hello Vijay,
>
> On 09/02/17 15:56, vijay.kil...@gmail.com wrote:
>>
>> From: Vijaya Kumar K 
>>
>> Right not CONFIG_NUMA is not enabled for ARM and
>
>
> s/not/now/
>
>> existing code in asm-arm/numa.h is for !COFIG_NUMA.
>
>
> s/COFIG_NUMA/CONFIG_NUMA/
>
>> Hence put this code under #ifndef CONFIG_NUMA.
>>
>> This help to make this changes work when CONFIG_NUMA
>> is not enabled.
>>
>
> Is there any reason to let the choice to the user to enable/disable NUMA?

I see no reason. Atleast in case of x86, I see it is enabled always.

>
>> Also define NODES_SHIFT macro for ARM.
>>
>> Signed-off-by: Vijaya Kumar K 
>> ---
>>  xen/include/asm-arm/numa.h | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/xen/include/asm-arm/numa.h b/xen/include/asm-arm/numa.h
>> index a2c1a34..a60c7eb 100644
>> --- a/xen/include/asm-arm/numa.h
>> +++ b/xen/include/asm-arm/numa.h
>> @@ -3,6 +3,9 @@
>>
>>  typedef u8 nodeid_t;
>>
>> +#define NODES_SHIFT 2
>
>
> Why 2?

Just to support upto 4 node system.

>
>> +
>> +#ifndef CONFIG_NUMA
>>  /* Fake one node for now. See also node_online_map. */
>>  #define cpu_to_node(cpu) 0
>>  #define node_to_cpumask(node)   (cpu_online_map)
>> @@ -16,6 +19,7 @@ static inline __attribute__((pure)) nodeid_t
>> phys_to_nid(paddr_t addr)
>>  #define node_spanned_pages(nid) (total_pages)
>>  #define node_start_pfn(nid) (pdx_to_pfn(frametable_base_pdx))
>>  #define __node_distance(a, b) (20)
>> +#endif /* CONFIG_NUMA */
>>
>>  static inline unsigned int arch_get_dma_bitsize(void)
>>  {
>>
>
> Cheers,
>
> --
> Julien Grall

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

Re: [Xen-devel] [PATCH 10/10] x86/cpuid: Always enable faulting for the control domain

[Jan Beulich]

>>> On 20.02.17 at 12:00,  wrote:
> The domain builder in libxc no longer depends on leaked CPUID information to
> properly construct HVM domains.  Remove the control domain exclusion.

Am I missing some intermediate step? As long as there's a raw
CPUID invocation in xc_cpuid_x86.c (which is still there in staging
and I don't recall this series removing it) it at least _feels_ unsafe.

Also the change here then results in Dom0 observing different
behavior between faulting-capable and faulting-incapable hosts.
I'm not convinced this is desirable.

Jan


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

Re: [Xen-devel] [PATCH 06/10] x86/cpuid: Handle leaf 0x6 in guest_cpuid()

[Jan Beulich]

>>> On 22.02.17 at 10:12,  wrote:
> On 22/02/17 08:23, Andrew Cooper wrote:
>> On 22/02/17 07:31, Jan Beulich wrote:
>> On 21.02.17 at 18:40,  wrote:
 On 21/02/17 17:25, Jan Beulich wrote:
 On 20.02.17 at 12:00,  wrote:
>> The PV MSR handling logic as minimal support for some thermal/perf 
>> operations
>> from the hardware domain, so leak through the implemented subset of 
>> features.
> Does it make sense to continue to special case PV hwdom here?
 Being able to play with these MSRs will be actively wrong for HVM
 context.  It is already fairly wrong for PV context, as nothing prevents
 you being rescheduled across pcpus while in the middle of a read/write
 cycle on the MSRs.
>>> So the MSRs in question are, afaics
>>> - MSR_IA32_MPERF, MSR_IA32_APERF, MSR_IA32_PERF_CTL (all
>>>   of which are is_cpufreq_controller() dependent)
>>> - MSR_IA32_THERM_CONTROL, MSR_IA32_ENERGY_PERF_BIAS
>>>   (both of which are is_pinned_vcpu() dependent)
>>> For the latter your argument doesn't apply. For the former, I've
>>> been wondering for a while whether we shouldn't do away with
>>> "cpufreq=dom0-kernel".
>> Hmm.  All good points.  If I can get away without leaking any of this,
>> that would be ideal.  (Lets see what Linux thinks of such a setup.)
> 
> Linux seems fine without any of this leakage.

But is that for a broad range of versions, or just the one you had
to hand?

Jan


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

Re: [Xen-devel] [PATCH 09/10] x86/cpuid: Drop legacy CPUID infrastructure

[Jan Beulich]

>>> On 20.02.17 at 12:00,  wrote:
> Now that all leaves have been altered to use the guest_cpuid() path, remove
> all the remaining legacy infrastructure.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 

> ---
>  xen/arch/x86/cpuid.c| 76 
> -
>  xen/arch/x86/domctl.c   | 45 +--
>  xen/include/asm-x86/cpuid.h | 27 
>  3 files changed, 1 insertion(+), 147 deletions(-)

Nice.

Jan


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

[Xen-devel] VLAPIC and Event channel relationship or how to map PIRQ to HVM guest

[Dmitry Rockosov]

Hello guys,

Could someone help me with VLAPIC and Event channel relationship? I can't
find any good design overview for it.
Are they compatible things or not?

Actually I want to map any PIRQ to HVM guest (for example keyboard), and
use VLAPIC to deliver virtual interrupt to HVM guest.
But seems like all interrupts from keyboard are working through the Event
Channel Upcall Interrupt with vector 243.

Please, help me or point any useful documentation.

Thank you!

Best Regards,
Rockosov Dmitry
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 2/3] x86/vpmu: Disable VPMU if guest's CPUID indicates no PMU support

[Jan Beulich]

>>> On 17.02.17 at 18:40,  wrote:
> --- a/xen/arch/x86/cpu/vpmu_intel.c
> +++ b/xen/arch/x86/cpu/vpmu_intel.c
> @@ -884,6 +884,10 @@ int vmx_vpmu_initialise(struct vcpu *v)
>  if ( vpmu_mode == XENPMU_MODE_OFF )
>  return 0;
>  
> +if ( MASK_EXTR(v->domain->arch.cpuid->basic.raw[0xa].a, 
> +   PMU_VERSION_MASK) == 0 )
> +return -EINVAL;

How about other unsupported (too large) values?

Jan


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

Re: [Xen-devel] [PATCH 10/10] x86/cpuid: Always enable faulting for the control domain

[Andrew Cooper]

On 22/02/17 09:23, Jan Beulich wrote:
 On 20.02.17 at 12:00,  wrote:
>> The domain builder in libxc no longer depends on leaked CPUID information to
>> properly construct HVM domains.  Remove the control domain exclusion.
> Am I missing some intermediate step? As long as there's a raw
> CPUID invocation in xc_cpuid_x86.c (which is still there in staging
> and I don't recall this series removing it) it at least _feels_ unsafe.

Strictly speaking, the domain builder part of this was completed after
my xsave adjustments.  All the guest-type-dependent information now
comes from non-cpuid sources in libxc, or Xen ignores the toolstack
values and recalculates information itself.

However, until the Intel leaves were complete, dom0 had a hard time
booting with this change as there were no toolstack-provided policy and
no leakage from hardware.

>
> Also the change here then results in Dom0 observing different
> behavior between faulting-capable and faulting-incapable hosts.
> I'm not convinced this is desirable.

I disagree.  Avoiding the leakage is very desirable moving forwards.

Other side effects are that it makes PV and PVH dom0 functionally
identical WRT CPUID, and PV userspace (which, unlikely the kernel, tends
not to be Xen-aware) sees sensible information.

~Andrew

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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf e0307a7dad02aa8c0cd8b3b0b9edce8ddb3fef2e
baseline version:
 ovmf 85520606ad459ba7d825c7ea5f225cffa1dbe95b

Last test of basis   105949  2017-02-21 12:00:06 Z0 days
Testing same since   105963  2017-02-21 21:43:31 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 
  Jiewen Yao 
  Laszlo Ersek 

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



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

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

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

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


Pushing revision :

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

Re: [Xen-devel] [xen-4.7-testing test] 105948: regressions - FAIL

[Dario Faggioli]

On Wed, 2017-02-22 at 01:46 -0700, Jan Beulich wrote:
> > > > On 22.02.17 at 01:02,  wrote:
> > (XEN) Xen call trace:
> > (XEN)[]
> > sched_credit2.c#vcpu_is_migrateable+0x22/0x9a
> > (XEN)[]
> > sched_credit2.c#csched2_schedule+0x823/0xb4e
> > (XEN)[] schedule.c#schedule+0x108/0x609
> > (XEN)[] softirq.c#__do_softirq+0x7f/0x8a
> > (XEN)[] do_softirq+0x13/0x15
> > (XEN)[] domain.c#idle_loop+0x55/0x62
> > (XEN)
> > (XEN)
> > (XEN) 
> > (XEN) Panic on CPU 14:
> > (XEN) Assertion 'd->cpupool != NULL' failed at
> > ...5948.build-amd64/xen/xen/include/xen/sched-if.h:200
> > (XEN) 
> > (XEN)
> > (XEN) Manual reset required ('noreboot' specified)
> > 
> > I am guessing the most recent credit2 backports weren't quite so
> > safe?
> 
> Well, there was only one in the batch under test (and that is what
> adds the cpupool_domain_cpumask() causing the ASSERT() above
> to trigger). However, comparing with the staging version of the file
> (which is heavily different), the immediate code involved here isn't
> all that different, so I wonder whether (a) this is a problem on
> staging too or (b) we're missing another backport.
>
Yeah, I also wonder in which of these two situations we are. Staging
looks fine, as far as my testing goes, and also according, e.g., to:

http://logs.test-lab.xenproject.org/osstest/logs/105946/test-amd64-amd64-xl-credit2/info.html

Or:

http://logs.test-lab.xenproject.org/osstest/logs/105900/test-amd64-amd64-xl-credit2/info.html

There appear to have been a problem, in a different test step, though,
here:
http://logs.test-lab.xenproject.org/osstest/logs/105919/test-amd64-amd64-xl-credit2/info.html

Which I noticed yesterday afternoon and am currently looking into it,
because I don't see what has actually gone wrong.

Also, looking at the history of Credit2 tests in 4.7-testing:
http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-amd64-xl-credit2/xen-4.7-testing

Things were fine on 2017-02-16, and have started failing 2017-02-20.

>  Dario?
> 
I will investigate.

Thanks and Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D 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] [RFC PATCH v1 02/21] x86: NUMA: Refactor NUMA code

[Vijay Kilari]

On Mon, Feb 20, 2017 at 6:07 PM, Julien Grall  wrote:
> Hello Vijay,
>
>
> On 09/02/17 15:56, vijay.kil...@gmail.com wrote:
>>
>> From: Vijaya Kumar K 
>>
>> Move common generic NUMA code to xen/common/numa.c from
>> xen/arch/x86/numa.c. Also move generic code in header file
>> xen/include/asm-x86/numa.h to xen/include/xen/numa.h
>>
>> This common code can be re-used later for ARM.
>>
>> Signed-off-by: Vijaya Kumar K 
>> ---
>>  xen/arch/x86/numa.c| 299 ---
>>  xen/common/Makefile|   1 +
>>  xen/common/numa.c  | 342
>> +
>>  xen/include/asm-x86/numa.h |  47 ---
>>  xen/include/xen/numa.h |  54 +++
>>  5 files changed, 397 insertions(+), 346 deletions(-)
>>
>> diff --git a/xen/arch/x86/numa.c b/xen/arch/x86/numa.c
>> index 6f4d438..bc787e0 100644
>> --- a/xen/arch/x86/numa.c
>> +++ b/xen/arch/x86/numa.c
>> @@ -25,27 +25,12 @@ custom_param("numa", numa_setup);
>>  #define Dprintk(x...)
>>  #endif
>>
>> -/* from proto.h */
>> -#define round_up(x,y) x)+(y))-1) & (~((y)-1)))
>> -
>> -struct node_data node_data[MAX_NUMNODES];
>> -
>> -/* Mapping from pdx to node id */
>> -int memnode_shift;
>> -static typeof(*memnodemap) _memnodemap[64];
>> -unsigned long memnodemapsize;
>> -u8 *memnodemap;
>> -
>> -nodeid_t cpu_to_node[NR_CPUS] __read_mostly = {
>> -[0 ... NR_CPUS-1] = NUMA_NO_NODE
>> -};
>>  /*
>>   * Keep BIOS's CPU2node information, should not be used for memory
>> allocaion
>>   */
>>  nodeid_t apicid_to_node[MAX_LOCAL_APIC] = {
>>  [0 ... MAX_LOCAL_APIC-1] = NUMA_NO_NODE
>>  };
>> -cpumask_t node_to_cpumask[MAX_NUMNODES] __read_mostly;
>>
>>  nodemask_t __read_mostly node_online_map = { { [0] = 1UL } };
>
>
> Why this variable is not moved?
Ok. Can be moved.
>
> [...]
>
>>  void __init numa_init_array(void)
>
>
> Same question for this function.

Initially I was suspicious about the comment in this function and thought
it might be valid of x86 alone. But looks like it is generic.
I will have a look.

>
>>  {
>>  int rr, i;
>> @@ -288,16 +145,6 @@ void __init numa_initmem_init(unsigned long
>> start_pfn, unsigned long end_pfn)
>>  (u64)end_pfn << PAGE_SHIFT);
>>  }
>>
>> -void numa_add_cpu(int cpu)
>> -{
>> -cpumask_set_cpu(cpu, &node_to_cpumask[cpu_to_node(cpu)]);
>> -}
>> -
>> -void numa_set_node(int cpu, nodeid_t node)
>> -{
>> -cpu_to_node[cpu] = node;
>> -}
>> -
>>  /* [numa=off] */
>>  static __init int numa_setup(char *opt)
>
>
> Same question here. Everything in numa_setup and the fake NUMA looks
> valid for ARM too.

numa_setup() is taken in separate patch. fake numa case is not considered.
for x86 it is under separate config CONFIG_NUMA_EMU.

>
> []
>
>> diff --git a/xen/common/Makefile b/xen/common/Makefile
>> index 0fed30b..c1bd2ff 100644
>> --- a/xen/common/Makefile
>> +++ b/xen/common/Makefile
>> @@ -63,6 +63,7 @@ obj-y += wait.o
>>  obj-bin-y += warning.init.o
>>  obj-$(CONFIG_XENOPROF) += xenoprof.o
>>  obj-y += xmalloc_tlsf.o
>> +obj-y += numa.o
>
>
> This needs to be gated with CONFIG_NUMA.

As it is shared with x86 and prior this changes it is not gated under
any config for x86.

>
>>
>>  obj-bin-$(CONFIG_X86) += $(foreach n,decompress bunzip2 unxz unlzma unlzo
>> unlz4 earlycpio,$(n).init.o)
>>
>> diff --git a/xen/common/numa.c b/xen/common/numa.c
>> new file mode 100644
>> index 000..59dcb63
>> --- /dev/null
>> +++ b/xen/common/numa.c
>> @@ -0,0 +1,342 @@
>> +/*
>> + * Common NUMA handling functions for x86 and arm.
>> + * Original code extracted from arch/x86/numa.c
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>
>
> Xen is GPLv2 only. Please update to:
>
> "This program is free software; you can redistribute it and/or
> modify it under the terms and conditions of the GNU General Public
> License, version 2, as published by the Free Software Foundation."
>
>
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program; If not, see .
>> + */
>> +
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +struct node_data node_data[MAX_NUMNODES];
>> +
>> +/* Mapping from pdx to node id */
>
>
> Looking at this comment, it looks like the NUMA support should depend on
> HAS_PDX as this is not something that ma

Re: [Xen-devel] [RFC PATCH v1 03/21] NUMA: Move arch specific NUMA code as common

[Vijay Kilari]

On Mon, Feb 20, 2017 at 6:17 PM, Julien Grall  wrote:
> Hello Vijay,
>
>
> On 09/02/17 15:56, vijay.kil...@gmail.com wrote:
>>
>> From: Vijaya Kumar K 
>>
>> Move some common numa code from xen/arch/x86/srat.c
>> to xen/common/numa.c
>>
>> Signed-off-by: Vijaya Kumar K 
>> ---
>>  xen/arch/x86/srat.c| 54
>> -
>>  xen/common/numa.c  | 55
>> ++
>>  xen/include/asm-x86/acpi.h |  1 -
>>  xen/include/asm-x86/numa.h |  1 -
>>  xen/include/xen/numa.h |  5 -
>>  5 files changed, 63 insertions(+), 53 deletions(-)
>>
>> diff --git a/xen/arch/x86/srat.c b/xen/arch/x86/srat.c
>> index d86783e..58dee09 100644
>> --- a/xen/arch/x86/srat.c
>> +++ b/xen/arch/x86/srat.c
>> @@ -25,7 +25,7 @@ static struct acpi_table_slit *__read_mostly acpi_slit;
>>
>>  static nodemask_t memory_nodes_parsed __initdata;
>>  static nodemask_t processor_nodes_parsed __initdata;
>> -static struct node nodes[MAX_NUMNODES] __initdata;
>> +extern struct node nodes[MAX_NUMNODES] __initdata;
>>
>>  struct pxm2node {
>> unsigned pxm;
>> @@ -36,9 +36,9 @@ static struct pxm2node __read_mostly
>> pxm2node[MAX_NUMNODES] =
>>
>>  static unsigned node_to_pxm(nodeid_t n);
>>
>> -static int num_node_memblks;
>> -static struct node node_memblk_range[NR_NODE_MEMBLKS];
>> -static nodeid_t memblk_nodeid[NR_NODE_MEMBLKS];
>> +extern int num_node_memblks;
>> +extern struct node node_memblk_range[NR_NODE_MEMBLKS];
>> +extern nodeid_t memblk_nodeid[NR_NODE_MEMBLKS];
>>  static __initdata DECLARE_BITMAP(memblk_hotplug, NR_NODE_MEMBLKS);
>>
>>  static inline bool_t node_found(unsigned idx, unsigned pxm)
>> @@ -103,52 +103,6 @@ nodeid_t setup_node(unsigned pxm)
>> return node;
>>  }
>>
>> -int valid_numa_range(u64 start, u64 end, nodeid_t node)
>> -{
>> -   int i;
>> -
>> -   for (i = 0; i < num_node_memblks; i++) {
>> -   struct node *nd = &node_memblk_range[i];
>> -
>> -   if (nd->start <= start && nd->end > end &&
>> -   memblk_nodeid[i] == node )
>> -   return 1;
>> -   }
>> -
>> -   return 0;
>> -}
>> -
>> -static __init int conflicting_memblks(u64 start, u64 end)
>> -{
>> -   int i;
>> -
>> -   for (i = 0; i < num_node_memblks; i++) {
>> -   struct node *nd = &node_memblk_range[i];
>> -   if (nd->start == nd->end)
>> -   continue;
>> -   if (nd->end > start && nd->start < end)
>> -   return i;
>> -   if (nd->end == end && nd->start == start)
>> -   return i;
>> -   }
>> -   return -1;
>> -}
>> -
>> -static __init void cutoff_node(int i, u64 start, u64 end)
>> -{
>> -   struct node *nd = &nodes[i];
>> -   if (nd->start < start) {
>> -   nd->start = start;
>> -   if (nd->end < nd->start)
>> -   nd->start = nd->end;
>> -   }
>> -   if (nd->end > end) {
>> -   nd->end = end;
>> -   if (nd->start > nd->end)
>> -   nd->start = nd->end;
>> -   }
>> -}
>> -
>>  static __init void bad_srat(void)
>>  {
>> int i;
>> diff --git a/xen/common/numa.c b/xen/common/numa.c
>> index 59dcb63..13f147c 100644
>> --- a/xen/common/numa.c
>> +++ b/xen/common/numa.c
>> @@ -46,6 +46,61 @@ nodeid_t cpu_to_node[NR_CPUS] __read_mostly = {
>>
>>  cpumask_t node_to_cpumask[MAX_NUMNODES] __read_mostly;
>>
>> +int num_node_memblks;
>> +struct node node_memblk_range[NR_NODE_MEMBLKS];
>> +nodeid_t memblk_nodeid[NR_NODE_MEMBLKS];
>> +struct node nodes[MAX_NUMNODES] __initdata;
>> +
>> +int valid_numa_range(u64 start, u64 end, nodeid_t node)
>
>
> I am not sure why you move this code in common code when it is not even used
> in your series.
Yes, it is used only by x86 but code is generic. I will keep in x86 to
void further
comments on this function.

>
> Furthermore, please use paddr_t rather than u64.
>
>> +{
>> +#ifdef CONFIG_NUMA
>
>
> common/numa.c should really not be compiled at all for configuration not
> supporting NUMA. In other words, I really don't want to see #ifdefery in
> common/numa.c.
>
>> +int i;
>> +
>> +for (i = 0; i < num_node_memblks; i++) {
>
>
> I know you are moving code around, but fix the coding style before hand
> would have been appreciated.
>
>> +struct node *nd = &node_memblk_range[i];
>> +
>> +if (nd->start <= start && nd->end > end &&
>> +memblk_nodeid[i] == node )
>> +return 1;
>> +}
>> +
>> +return 0;
>> +#else
>> +return 1;
>> +#endif
>> +}
>> +
>> +__init int conflicting_memblks(u64 start, u64 end)
>
>
> Ditto for u64.
OK
>
>> +{
>> +int i;
>> +
>> +for (i = 0; i < num_node_memblks; i++) {
>> +struct node *nd = &node_memblk_range[i];
>> +if (nd->start == nd->end)
>> +continue;
>> +if (nd->end > start && nd->start < end)
>> 

Re: [Xen-devel] [PATCH v6 7/7] xen/x86: setup PVHv2 Dom0 ACPI tables

[Jan Beulich]

>>> On 10.02.17 at 13:33,  wrote:
> Changes since v5:
>  - s/hvm_copy_to_guest_phys_vcpu/hvm_copy_to_guest_phys/.
>  - Move pvh_add_mem_range to previous patch.
>  - Add a comment regarding the current limitation to only 1 emulated IO APIC.
>  - s/dom0_max_vcpus()/max_vcpus/ in pvh_setup_acpi_madt.
>  - Cast structures to void when assigning.
>  - Declare banned_tables with the initconst annotation.
>  - Expand some comments messages.
>  - Initialize the RSDP local variable.
>  - Only provide x2APIC entries in the MADT.

I've just checked the system I had mentioned earlier, and indeed
there's a mixture of x2APIC and LAPIC entries there, but no two
entries for the same CPU / APIC ID. So I guess as long as we're
convinced PVH guests are fine with finding just x2APIC entries we
can keep it that way, and if later we find the need to add LAPIC
entries, we may still do so. Of course this implies that PVH guests
must not assume to only find x2APIC entries. Hence
Reviewed-by: Jan Beulich 

Jan


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

Re: [Xen-devel] [PATCH 10/10] x86/cpuid: Always enable faulting for the control domain

[Jan Beulich]

>>> On 22.02.17 at 11:00,  wrote:
> On 22/02/17 09:23, Jan Beulich wrote:
> On 20.02.17 at 12:00,  wrote:
>>> The domain builder in libxc no longer depends on leaked CPUID information to
>>> properly construct HVM domains.  Remove the control domain exclusion.
>> Am I missing some intermediate step? As long as there's a raw
>> CPUID invocation in xc_cpuid_x86.c (which is still there in staging
>> and I don't recall this series removing it) it at least _feels_ unsafe.
> 
> Strictly speaking, the domain builder part of this was completed after
> my xsave adjustments.  All the guest-type-dependent information now
> comes from non-cpuid sources in libxc, or Xen ignores the toolstack
> values and recalculates information itself.
> 
> However, until the Intel leaves were complete, dom0 had a hard time
> booting with this change as there were no toolstack-provided policy and
> no leakage from hardware.

So what are the CPUID uses in libxc then needed for at this point?
Could they be removed in a prereq patch to make clear all needed
information is now being obtained via hypercalls?

>> Also the change here then results in Dom0 observing different
>> behavior between faulting-capable and faulting-incapable hosts.
>> I'm not convinced this is desirable.
> 
> I disagree.  Avoiding the leakage is very desirable moving forwards.
> 
> Other side effects are that it makes PV and PVH dom0 functionally
> identical WRT CPUID, and PV userspace (which, unlikely the kernel, tends
> not to be Xen-aware) sees sensible information.

I can see the upsides too, hence the "I'm not convinced" ...

Jan


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

Re: [Xen-devel] [PATCH v2 1/3] x86/vmx: introduce vmx_find_msr()

[Jan Beulich]

>>> On 22.02.17 at 09:45,  wrote:
> On Wed, 2017-02-22 at 08:40 +, Tian, Kevin wrote:
>> > From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
>> > Sent: Wednesday, February 22, 2017 4:38 PM
>> > 
>> > > > 
>> > > > -for ( idx = 0; idx < *msr_count; idx++ )
>> > > > +for ( idx = 0; (*msr_area)[idx].index <= msr && idx < *msr_count; 
>> > > > idx++ 
> )
>> > > 
>> > > risk of out-of-boundary access.
>> > 
>> > How exactly out-of-bounds access is possible? The original condition
>> > 
>> > idx < *msr_count
>> > 
>> > Is still being checked on each loop iteration.
>> > 
>> 
>> Isn't "(*msr_area[idx]).index <= msr" checked before "idx < *msr_count"?
>> 
>> So if idx==*msr_count, you first hit an out-of-boundary access...
>> 
>> I think we should change the condition order here.
>> 
> 
> You are right. I will fix this in v3.

And with that taken care of
Reviewed-by: Jan Beulich 



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

Re: [Xen-devel] [PATCH v2 2/3] x86/vmx: optimize vmx_read/write_guest_msr()

[Jan Beulich]

>>> On 17.02.17 at 16:42,  wrote:
> --- a/xen/arch/x86/hvm/vmx/vmcs.c
> +++ b/xen/arch/x86/hvm/vmx/vmcs.c
> @@ -1347,17 +1347,12 @@ struct vmx_msr_entry *vmx_find_msr(u32 msr, int type)
>  
>  int vmx_read_guest_msr(u32 msr, u64 *val)
>  {
> -struct vcpu *curr = current;
> -unsigned int i, msr_count = curr->arch.hvm_vmx.msr_count;
> -const struct vmx_msr_entry *msr_area = curr->arch.hvm_vmx.msr_area;
> +struct vmx_msr_entry *ent;
>  
> -for ( i = 0; i < msr_count; i++ )
> +if ( (ent = vmx_find_msr(msr, VMX_GUEST_MSR)) != NULL )

I think this would read better (less parentheses etc) as

struct vmx_msr_entry *ent = vmx_find_msr(msr, VMX_GUEST_MSR);
 
if ( ent )

but either way
Reviewed-by: Jan Beulich 

Jan


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

Re: [Xen-devel] [PATCH 08/10] x86/cpuid: Handle leaf 0xb in guest_cpuid()

[Andrew Cooper]

On 22/02/17 09:16, Jan Beulich wrote:
 On 20.02.17 at 12:00,  wrote:
>> Leaf 0xb is reserved by AMD, and uniformly hidden from guests by the 
>> toolstack
>> logic and hypervisor PV logic.
>>
>> The previous dynamic logic filled in the x2APIC ID for all HVM guests.  This
>> is modified to respect the entire leaf being reserved by AMD, but is altered
>> to include PV Intel guests, so they get more sensible values in their 
>> emulated
>> and faulted view of CPUID.
> Don't we expose x2APIC to HVM guests even on AMD systems? In
> which case we surely will want to also expose the x2APIC ID.

The x2apic feature bit is still listed as reserved in the latest AMD
SDM, and I haven't seen a piece of hardware which supports it.

Also, x2apic or not, this leaf is documented as fully reserved, so we
shouldn't be filling it in anyway.

>
>> @@ -959,6 +950,14 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf,
>>  }
>>  break;
>>  
>> +case 0xb:
>> +if ( p->x86_vendor == X86_VENDOR_INTEL )
>> +{
>> +/* Fix the x2APIC identifier. */
>> +res->d = v->vcpu_id * 2;
>> +}
>> +break;
> Irrespective of the comment above, wouldn't the if() here better
> look at the x2APIC feature flag of the domain?

Perhaps.  There isn't a formal link called out, but looking at the
content, I am guessing that real hardware is consistent with their
support of x2apic and the availability of this leaf?

~Andrew

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

[Xen-devel] [xen-unstable-coverity test] 105979: all pass - PUSHED

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 xen  b908131167a67a16fbe9c7a7826b67e2d93d9ec5
baseline version:
 xen  75da1b150e646bb9aaa26c5b2452f0c3e782d302

Last test of basis   105903  2017-02-19 09:19:52 Z3 days
Testing same since   105979  2017-02-22 09:20:39 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Boris Ostrovsky 
  George Dunlap 
  Jan Beulich 
  Kevin Tian 
  Norbert Manthey 
  Wei Liu 
  Zhang Chen 

jobs:
 coverity-amd64   pass



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

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

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

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


Pushing revision :

+ branch=xen-unstable-coverity
+ revision=b908131167a67a16fbe9c7a7826b67e2d93d9ec5
+ . ./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-coverity b908131167a67a16fbe9c7a7826b67e2d93d9ec5
+ branch=xen-unstable-coverity
+ revision=b908131167a67a16fbe9c7a7826b67e2d93d9ec5
+ . ./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-coverity
+ qemuubranch=qemu-upstream-unstable-coverity
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-coverity
+ prevxenbranch=xen-4.8-testing
+ '[' xb908131167a67a16fbe9c7a7826b67e2d93d9ec5 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable-coverity
++ : daily-cron

Re: [Xen-devel] [PATCH v2 3/3] x86/vmx: fix vmentry failure with TSX bits in LBR

[Jan Beulich]

>>> On 17.02.17 at 16:42,  wrote:
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -2284,6 +2284,8 @@ static void pi_notification_interrupt(struct 
> cpu_user_regs *regs)
>  raise_softirq(VCPU_KICK_SOFTIRQ);
>  }
>  
> +static void __init vmx_lbr_tsx_fixup_check(void);

vmx_ prefixes are pretty pointless for static functions in this
particular source file (there's at least one more below).

> @@ -2876,7 +2938,11 @@ static int vmx_msr_write_intercept(unsigned int msr, 
> uint64_t msr_content)
>  for ( ; (rc == 0) && lbr->count; lbr++ )
>  for ( i = 0; (rc == 0) && (i < lbr->count); i++ )
>  if ( (rc = vmx_add_guest_msr(lbr->base + i)) == 0 )
> +{
>  vmx_disable_intercept_for_msr(v, lbr->base + i, 
> MSR_TYPE_R | MSR_TYPE_W);
> +if ( vmx_lbr_tsx_fixup_needed )
> +v->arch.hvm_vmx.lbr_tsx_fixup_enabled = true;

Is there anything wrong with

v->arch.hvm_vmx.lbr_tsx_fixup_enabled = vmx_lbr_tsx_fixup_needed;

?

> --- a/xen/include/asm-x86/hvm/vmx/vmcs.h
> +++ b/xen/include/asm-x86/hvm/vmx/vmcs.h
> @@ -147,6 +147,7 @@ struct arch_vmx_struct {
>  uint8_t  vmx_realmode;
>  /* Are we emulating rather than VMENTERing? */
>  uint8_t  vmx_emulate;
> +bool lbr_tsx_fixup_enabled;
>  /* Bitmask of segments that we can't safely use in virtual 8086 mode */
>  uint16_t vm86_segment_mask;
>  /* Shadow CS, SS, DS, ES, FS, GS, TR while in virtual 8086 mode */

Please put blank lines around your addition.

> --- a/xen/include/asm-x86/msr-index.h
> +++ b/xen/include/asm-x86/msr-index.h
> @@ -55,6 +55,8 @@
>  #define MSR_IA32_PEBS_ENABLE 0x03f1
>  #define MSR_IA32_DS_AREA 0x0600
>  #define MSR_IA32_PERF_CAPABILITIES   0x0345
> +/* Lower 6 bits define the format of the address in the LBR stack */
> +#define LBR_FORMAT_MSR_IA32_PERF_CAP 0x3f

Commonly the MSR name precedes the field specific name component.

Jan


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

[Xen-devel] [qemu-upstream-unstable baseline-only test] 68598: regressions - trouble: blocked/broken/fail/pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 68598 qemu-upstream-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68598/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl  14 guest-saverestore fail REGR. vs. 68580

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

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
 build-arm64-xsm   2 hosts-allocate   broken never pass
 build-arm64   2 hosts-allocate   broken never pass
 build-arm64-pvops 2 hosts-allocate   broken never pass
 build-arm64-xsm   3 capture-logs broken never pass
 build-arm64   3 capture-logs broken never pass
 build-arm64-pvops 3 capture-logs broken never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  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-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 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-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass

version targeted for testing:
 qemuu57e8fbb2f702001a18bd81e9fe31b26d94247ac9
baseline version:
 qemuu08c008de9c7d3ac71f71c87cc04a47819ca228dc

Last test of basis68580  2017-02-18 10:46:44 Z3 days
Testing same since68598  2017-02-22 04:15:56 Z0 days1 attempts


People who touched revisions under test:
  Gerd Hoffmann 

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

Re: [Xen-devel] [RFC PATCH v1 04/21] NUMA: Refactor generic and arch specific code of numa_setup

[Vijay Kilari]

On Mon, Feb 20, 2017 at 7:09 PM, Julien Grall  wrote:
> Hello Vijay,
>
>
> On 09/02/17 15:56, vijay.kil...@gmail.com wrote:
>>
>> From: Vijaya Kumar K 
>>
>> numa_setup() contains generic and arch specific code.
>> Split numa_setup() and move architecture specific code
>> under arch_numa_setup().
>>
>> Signed-off-by: Vijaya Kumar K 
>> ---
>>  xen/arch/arm/Makefile  |  1 +
>>  xen/arch/arm/numa.c| 28 
>>  xen/arch/x86/numa.c| 11 +--
>>  xen/common/numa.c  | 14 ++
>>  xen/include/asm-arm/numa.h |  9 -
>>  xen/include/asm-x86/numa.h |  2 +-
>>  xen/include/xen/numa.h |  1 +
>>  7 files changed, 54 insertions(+), 12 deletions(-)
>>
>> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
>> index 7afb8a3..b5d7a19 100644
>> --- a/xen/arch/arm/Makefile
>> +++ b/xen/arch/arm/Makefile
>> @@ -49,6 +49,7 @@ obj-y += vm_event.o
>>  obj-y += vtimer.o
>>  obj-y += vpsci.o
>>  obj-y += vuart.o
>> +obj-$(CONFIG_NUMA) += numa.o
>>
>>  #obj-bin-y += o
>>
>> diff --git a/xen/arch/arm/numa.c b/xen/arch/arm/numa.c
>> new file mode 100644
>> index 000..59d09c7
>> --- /dev/null
>> +++ b/xen/arch/arm/numa.c
>> @@ -0,0 +1,28 @@
>> +/*
>> + * ARM NUMA Implementation
>> + *
>> + * Copyright (C) 2016 - Cavium Inc.
>> + * Vijaya Kumar K 
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>
>
> The copyright is wrong.
>
>
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +int __init arch_numa_setup(char *opt)
>> +{
>> +return 1;
>> +}
>> diff --git a/xen/arch/x86/numa.c b/xen/arch/x86/numa.c
>> index bc787e0..28d1891 100644
>> --- a/xen/arch/x86/numa.c
>> +++ b/xen/arch/x86/numa.c
>> @@ -18,9 +18,6 @@
>>  #include 
>>  #include 
>>
>> -static int numa_setup(char *s);
>> -custom_param("numa", numa_setup);
>> -
>>  #ifndef Dprintk
>>  #define Dprintk(x...)
>>  #endif
>> @@ -34,7 +31,6 @@ nodeid_t apicid_to_node[MAX_LOCAL_APIC] = {
>>
>>  nodemask_t __read_mostly node_online_map = { { [0] = 1UL } };
>>
>> -bool_t numa_off = 0;
>>  s8 acpi_numa = 0;
>>
>>  int srat_disabled(void)
>> @@ -145,13 +141,8 @@ void __init numa_initmem_init(unsigned long
>> start_pfn, unsigned long end_pfn)
>>  (u64)end_pfn << PAGE_SHIFT);
>>  }
>>
>> -/* [numa=off] */
>> -static __init int numa_setup(char *opt)
>> +int __init arch_numa_setup(char *opt)
>
>
> I don't understand why you split numa_setup. All the options look valid for
> ARM.

OK.  This is all valid for arm, provided CONFIG_NUMA_EMU is implemented.
Can be moved to generic and for now we can keep CONFIG_NUMA_EMU
disabled for arm.

>
>>  {
>> -if ( !strncmp(opt,"off",3) )
>> -numa_off = 1;
>> -if ( !strncmp(opt,"on",2) )
>> -numa_off = 0;
>>  #ifdef CONFIG_NUMA_EMU
>>  if ( !strncmp(opt, "fake=", 5) )
>>  {
>> diff --git a/xen/common/numa.c b/xen/common/numa.c
>> index 13f147c..9b9cf9c 100644
>> --- a/xen/common/numa.c
>> +++ b/xen/common/numa.c
>> @@ -32,6 +32,10 @@
>>  #include 
>>  #include 
>>
>> +static int numa_setup(char *s);
>
>
> Forward declaration can be avoided in most of the cases. So please add at
> the right place from the beginning.
>
>
>> +custom_param("numa", numa_setup);
>> +
>> +bool_t numa_off = 0;
>>  struct node_data node_data[MAX_NUMNODES];
>>
>>  /* Mapping from pdx to node id */
>> @@ -250,6 +254,16 @@ EXPORT_SYMBOL(memnode_shift);
>>  EXPORT_SYMBOL(memnodemap);
>>  EXPORT_SYMBOL(node_data);
>>
>> +static __init int numa_setup(char *opt)
>> +{
>> +if ( !strncmp(opt,"off",3) )
>> +numa_off = 1;
>> +if ( !strncmp(opt,"on",2) )
>> +numa_off = 0;
>> +
>> +return arch_numa_setup(opt);
>> +}
>> +
>>  static void dump_numa(unsigned char key)
>>  {
>>  s_time_t now = NOW();
>> diff --git a/xen/include/asm-arm/numa.h b/xen/include/asm-arm/numa.h
>> index a60c7eb..c1e8a7d 100644
>> --- a/xen/include/asm-arm/numa.h
>> +++ b/xen/include/asm-arm/numa.h
>> @@ -5,7 +5,14 @@ typedef u8 nodeid_t;
>>
>>  #define NODES_SHIFT 2
>>
>> -#ifndef CONFIG_NUMA
>> +#ifdef CONFIG_NUMA
>> +int arch_numa_setup(char *opt);
>> +#else
>> +static inline int arch_numa_setup(char *opt)
>> +{
>> +return 1;
>> +}
>
>
> What is the point of this?
>
>
>> +
>>  /* Fake one node for now. See also node_online_map. */
>>  #define cpu_to_node(cpu) 0
>>  #define node_to_cpumask(node)   (cpu_online_map)
>> diff --git a/xen/include/asm-x86/numa.h b/xen/include/asm-x86/numa.h
>> index df1f7d5..6

Re: [Xen-devel] [PATCH 08/10] x86/cpuid: Handle leaf 0xb in guest_cpuid()

[Jan Beulich]

>>> On 22.02.17 at 11:22,  wrote:
> On 22/02/17 09:16, Jan Beulich wrote:
> On 20.02.17 at 12:00,  wrote:
>>> Leaf 0xb is reserved by AMD, and uniformly hidden from guests by the 
> toolstack
>>> logic and hypervisor PV logic.
>>>
>>> The previous dynamic logic filled in the x2APIC ID for all HVM guests.  This
>>> is modified to respect the entire leaf being reserved by AMD, but is altered
>>> to include PV Intel guests, so they get more sensible values in their 
>>> emulated
>>> and faulted view of CPUID.
>> Don't we expose x2APIC to HVM guests even on AMD systems? In
>> which case we surely will want to also expose the x2APIC ID.
> 
> The x2apic feature bit is still listed as reserved in the latest AMD
> SDM, and I haven't seen a piece of hardware which supports it.

This doesn't seem to answer my question, as hardware behavior is
of no interest here (our emulation works on old Intel hardware too).
Just to be sure I've checked a HVM guest on an AMD box, and this
is what Linux reports:

<6>Enabling x2apic
<6>Enabled x2apic
<6>Switched APIC routing to physical x2apic.

> Also, x2apic or not, this leaf is documented as fully reserved, so we
> shouldn't be filling it in anyway.

While guests appear to do fine without, I think this is inconsistent
with providing x2APIC support. But as current behavior is the same,
we can as well leave this for the future.

>>> @@ -959,6 +950,14 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf,
>>>  }
>>>  break;
>>>  
>>> +case 0xb:
>>> +if ( p->x86_vendor == X86_VENDOR_INTEL )
>>> +{
>>> +/* Fix the x2APIC identifier. */
>>> +res->d = v->vcpu_id * 2;
>>> +}
>>> +break;
>> Irrespective of the comment above, wouldn't the if() here better
>> look at the x2APIC feature flag of the domain?
> 
> Perhaps.  There isn't a formal link called out, but looking at the
> content, I am guessing that real hardware is consistent with their
> support of x2apic and the availability of this leaf?

I suppose so, at least they've got introduced together iirc.

Jan


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

Re: [Xen-devel] [PATCH v2] x86/VMX: sanitize VM86 TSS handling

[Andrew Cooper]

On 17/02/17 12:03, Jan Beulich wrote:
> @@ -4267,6 +4336,12 @@ static int hvmop_get_param(
>  case HVM_PARAM_ACPI_S_STATE:
>  a.value = d->arch.hvm_domain.is_s3_suspended ? 3 : 0;
>  break;
> +
> +case HVM_PARAM_VM86_TSS:
> +a.value = (uint32_t)d->arch.hvm_domain.params
> +[HVM_PARAM_VM86_TSS_SIZED];
> +break;

HVM_PARAM_VM86_TSS_SIZED needs to have VM86_TSS_UPDATED masked out on a
read, or the guest and toolstack will observe a crazy size if they read
the param back before CR0.PE is cleared.

Otherwise, Reviewed-by: Andrew Cooper 

> +
>  case HVM_PARAM_X87_FIP_WIDTH:
>  a.value = d->arch.x87_fip_width;
>  break;


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

Re: [Xen-devel] [RFC PATCH v1 06/21] ARM: NUMA: Parse CPU NUMA information

[Vijay Kilari]

On Mon, Feb 20, 2017 at 11:02 PM, Julien Grall  wrote:
> Hello Vijay,
>
> On 09/02/17 15:56, vijay.kil...@gmail.com wrote:
>>
>> From: Vijaya Kumar K 
>>
>> Parse CPU node and fetch numa-node-id information.
>> For each node-id found, update nodemask_t mask.
>
>
> A link to the bindings would have been useful...
>
>> Call numa_init() from setup_mm() with start and end
>> pfn of the complete ram..
>
>
> s/.././
>
>
>> Signed-off-by: Vijaya Kumar K 
>> ---
>>  xen/arch/arm/Makefile |  1 +
>>  xen/arch/arm/bootfdt.c|  8 ++---
>>  xen/arch/arm/dt_numa.c| 72
>> +++
>>  xen/arch/arm/numa.c   | 14 +
>>  xen/arch/arm/setup.c  |  3 ++
>>  xen/include/asm-arm/numa.h| 14 +
>>  xen/include/xen/device_tree.h |  4 +++
>>  7 files changed, 112 insertions(+), 4 deletions(-)
>>
>> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
>> index b5d7a19..7694485 100644
>> --- a/xen/arch/arm/Makefile
>> +++ b/xen/arch/arm/Makefile
>> @@ -50,6 +50,7 @@ obj-y += vtimer.o
>>  obj-y += vpsci.o
>>  obj-y += vuart.o
>>  obj-$(CONFIG_NUMA) += numa.o
>> +obj-$(CONFIG_NUMA) += dt_numa.o
>
>
> I would prefer if we introduce a directly numa within arm. This would make
> the root cleaner.

As it is very specific to DT, I have introduced in this file. ACPI is
implemented
in separate file. Common arm specific numa code is in numa.c file.

>
>
>>
>>  #obj-bin-y += o
>>
>> diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
>> index 979f675..d1122d8 100644
>> --- a/xen/arch/arm/bootfdt.c
>> +++ b/xen/arch/arm/bootfdt.c
>> @@ -17,8 +17,8 @@
>>  #include 
>>  #include 
>>
>> -static bool_t __init device_tree_node_matches(const void *fdt, int node,
>> -  const char *match)
>> +bool_t __init device_tree_node_matches(const void *fdt, int node,
>> +   const char *match)
>>  {
>>  const char *name;
>>  size_t match_len;
>> @@ -63,8 +63,8 @@ static void __init device_tree_get_reg(const __be32
>> **cell, u32 address_cells,
>>  *size = dt_next_cell(size_cells, cell);
>>  }
>>
>> -static u32 __init device_tree_get_u32(const void *fdt, int node,
>> -  const char *prop_name, u32 dflt)
>> +u32 __init device_tree_get_u32(const void *fdt, int node,
>> +   const char *prop_name, u32 dflt)
>>  {
>>  const struct fdt_property *prop;
>>
>> diff --git a/xen/arch/arm/dt_numa.c b/xen/arch/arm/dt_numa.c
>> new file mode 100644
>> index 000..4b94c36
>> --- /dev/null
>> +++ b/xen/arch/arm/dt_numa.c
>> @@ -0,0 +1,72 @@
>> +/*
>> + * OF NUMA Parsing support.
>> + *
>> + * Copyright (C) 2015 - 2016 Cavium Inc.
>> + *
>> + * Some code extracts are taken from linux drivers/of/of_numa.c
>
>
> Please specify which code has been extract from Linux and the commit id.
>
> Looking at this patch only, none of this code is from Linux. Or it has been
> heavily modified.
It is heavily modified. I will drop this statement.

>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program.  If not, see .
>> + */
>> +
>> +#include 
>
>
> No need to include xen/config.h
>
>> +#include 
>
>
> This include should not be there as the device tree is not yet parsed.
>
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +nodemask_t numa_nodes_parsed;
>
>
> Why does this variable live in dt_numa.c when this is used by common and
> acpi code?
>
> Also, any variable/function exported should have there prototype in the
> associated header.

ok. will check.
>
>> +
>> +/*
>> + * Even though we connect cpus to numa domains later in SMP
>> + * init, we need to know the node ids now for all cpus.
>> +*/
>
>
> Coding style:
>
> /*
>  * ...
>
>  */
>
>> +static int __init dt_numa_process_cpu_node(const void *fdt, int node,
>> +   const char *name,
>> +   u32 address_cells, u32
>> size_cells)
>> +{
>> +u32 nid;
>> +
>> +nid = device_tree_get_u32(fdt, node, "numa-node-id", MAX_NUMNODES);
>> +
>> +if ( nid >= MAX_NUMNODES )
>> +printk(XENLOG_WARNING "NUMA: Node id %u exceeds maximum value\n",
>> nid);
>> +else
>> +node_set(nid, numa_nodes_parsed);
>> +
>> +return 0;
>> +}
>> +
>> +static int __init dt_numa_scan_cpu_node(const void *fdt, int node,
>

Re: [Xen-devel] [RFC PATCH v1 01/21] ARM: NUMA: Add existing ARM numa code under CONFIG_NUMA

[Julien Grall]

Hello Vijay,

On 22/02/17 09:18, Vijay Kilari wrote:

On Mon, Feb 20, 2017 at 5:09 PM, Julien Grall  wrote:

Hello Vijay,

On 09/02/17 15:56, vijay.kil...@gmail.com wrote:


From: Vijaya Kumar K 

Right not CONFIG_NUMA is not enabled for ARM and



s/not/now/


existing code in asm-arm/numa.h is for !COFIG_NUMA.



s/COFIG_NUMA/CONFIG_NUMA/


Hence put this code under #ifndef CONFIG_NUMA.

This help to make this changes work when CONFIG_NUMA
is not enabled.



Is there any reason to let the choice to the user to enable/disable NUMA?


I see no reason. Atleast in case of x86, I see it is enabled always.


Stefano, do you have any opinion on whether a user should be able to 
enable/disable NUMA?





Also define NODES_SHIFT macro for ARM.

Signed-off-by: Vijaya Kumar K 
---
 xen/include/asm-arm/numa.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/xen/include/asm-arm/numa.h b/xen/include/asm-arm/numa.h
index a2c1a34..a60c7eb 100644
--- a/xen/include/asm-arm/numa.h
+++ b/xen/include/asm-arm/numa.h
@@ -3,6 +3,9 @@

 typedef u8 nodeid_t;

+#define NODES_SHIFT 2



Why 2?


Just to support upto 4 node system.


Why only 4 node supported? Also, this should be specified in the commit 
message.


Regards,

--
Julien Grall

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

Re: [Xen-devel] [RFC PATCH v1 02/21] x86: NUMA: Refactor NUMA code

[Julien Grall]

Hello Vijay,

On 22/02/17 10:04, Vijay Kilari wrote:

On Mon, Feb 20, 2017 at 6:07 PM, Julien Grall  wrote:



 {
 int rr, i;
@@ -288,16 +145,6 @@ void __init numa_initmem_init(unsigned long
start_pfn, unsigned long end_pfn)
 (u64)end_pfn << PAGE_SHIFT);
 }

-void numa_add_cpu(int cpu)
-{
-cpumask_set_cpu(cpu, &node_to_cpumask[cpu_to_node(cpu)]);
-}
-
-void numa_set_node(int cpu, nodeid_t node)
-{
-cpu_to_node[cpu] = node;
-}
-
 /* [numa=off] */
 static __init int numa_setup(char *opt)



Same question here. Everything in numa_setup and the fake NUMA looks
valid for ARM too.


numa_setup() is taken in separate patch. fake numa case is not considered.
for x86 it is under separate config CONFIG_NUMA_EMU.


Why fake numa is not considered? This would help to test the series on 
non-NUMA platform.




[]


diff --git a/xen/common/Makefile b/xen/common/Makefile
index 0fed30b..c1bd2ff 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -63,6 +63,7 @@ obj-y += wait.o
 obj-bin-y += warning.init.o
 obj-$(CONFIG_XENOPROF) += xenoprof.o
 obj-y += xmalloc_tlsf.o
+obj-y += numa.o



This needs to be gated with CONFIG_NUMA.


As it is shared with x86 and prior this changes it is not gated under
any config for x86.


Because x86 code assume that CONFIG_NUMA is always enabled. If you look 
at the .config CONFIG_NUMA will be set so you can gate it here.



Looking at this comment, it looks like the NUMA support should depend on
HAS_PDX as this is not something that may be able on all the architecture.


yes it uses pfn_to_pdx() while updating memnodemap.
May be comment should be suffice.


A comment may be missed, gated in the Kconfig will prevent a new 
architecture to use NUMA without knowing PDX is necessary.


[...]


+#endif /* CONFIG_NUMA */
+
+extern void numa_add_cpu(int cpu);
+extern nodeid_t setup_node(unsigned int pxm);
+extern void numa_set_node(int cpu, nodeid_t node);
+extern void setup_node_bootmem(nodeid_t nodeid, u64 start, u64 end);



I am not sure to understand why those function are not protected by #ifdef
CONFIFG_NUMA.

As these defined in xen/common/numa.c which is not under CONFIG_NUMA,
I have kept them outside CONFIG_NUMA


xen/common/numa.c should be under CONFIG_NUMA. There is no reason to 
expose the code on non-NUMA platform.


Regards,

--
Julien Grall

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

[Xen-devel] [PATCH 1/2] Add libxendevicemodel to rpath-link

[Paul Durrant]

libxenctrl now depends on this library

Signed-off-by: Paul Durrant 
--
Cc: Ian Jackson 
---
 xen-hooks.mak | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen-hooks.mak b/xen-hooks.mak
index c1ea4be..4356f67 100644
--- a/xen-hooks.mak
+++ b/xen-hooks.mak
@@ -28,6 +28,7 @@ LIBS += -L$(XEN_ROOT)/tools/xenstore -lxenstore
 LIBS += -Wl,-rpath-link=$(XEN_ROOT)/tools/libs/toollog
 LIBS += -Wl,-rpath-link=$(XEN_ROOT)/tools/libs/call
 LIBS += -Wl,-rpath-link=$(XEN_ROOT)/tools/libs/foreignmemory
+LIBS += -Wl,-rpath-link=$(XEN_ROOT)/tools/libs/devicemodel
 
 LDFLAGS := $(CFLAGS) $(LDFLAGS)
 
-- 
2.1.4


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

[Xen-devel] [PATCH 2/2] Request compatibility interface for device model operations

[Paul Durrant]

Now that these have been split out of libxenctrl into libxendevicemodel
QEMU needs to request the compatibility interface.

Signed-off-by: Paul Durrant 
--
Cc: Ian Jackson 
---
 xen-hooks.mak | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen-hooks.mak b/xen-hooks.mak
index 4356f67..0ca868f 100644
--- a/xen-hooks.mak
+++ b/xen-hooks.mak
@@ -2,6 +2,7 @@ CPPFLAGS+= -I$(XEN_ROOT)/tools/libs/toollog/include
 CPPFLAGS+= -I$(XEN_ROOT)/tools/libs/evtchn/include
 CPPFLAGS+= -I$(XEN_ROOT)/tools/libs/gnttab/include
 CPPFLAGS+= -DXC_WANT_COMPAT_MAP_FOREIGN_API
+CPPFLAGS+= -DXC_WANT_COMPAT_DEVICEMODEL_API
 CPPFLAGS+= -I$(XEN_ROOT)/tools/libxc/include
 CPPFLAGS+= -I$(XEN_ROOT)/tools/xenstore/include
 CPPFLAGS+= -I$(XEN_ROOT)/tools/include
-- 
2.1.4


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

[Xen-devel] [PATCH] Include libxendevicemodel with libxc

[Paul Durrant]

libxendevicemodel has just been split out from libxc. From mini-os's
point of view we don't care about the distinction, so keep things
simple by just including libxendevicemodel if libxc is enabled.

Signed-off-by: Paul Durrant 
--
Cc: Samuel Thibault 
---
 Makefile | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Makefile b/Makefile
index 74f2c31..ef8559b 100644
--- a/Makefile
+++ b/Makefile
@@ -134,6 +134,8 @@ APP_LDLIBS += 
-L$(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/call -whole-archi
 LIBS += $(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/call/libxencall.a
 APP_LDLIBS += -L$(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/foreignmemory 
-whole-archive -lxenforeignmemory -no-whole-archive
 LIBS += 
$(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/foreignmemory/libxenforeignmemory.a
+APP_LDLIBS += -L$(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/devicemodel 
-whole-archive -lxendevicemodel -no-whole-archive
+LIBS += 
$(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/devicemodel/libxendevicemodel.a
 APP_LDLIBS += -L$(XEN_ROOT)/stubdom/libxc-$(MINIOS_TARGET_ARCH) -whole-archive 
-lxenguest -lxenctrl -no-whole-archive
 LIBS += $(XEN_ROOT)/stubdom/libxc-$(MINIOS_TARGET_ARCH)/libxenctrl.a
 LIBS += $(XEN_ROOT)/stubdom/libxc-$(MINIOS_TARGET_ARCH)/libxenguest.a
-- 
2.1.4


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

Re: [Xen-devel] [PATCH] Include libxendevicemodel with libxc

[Samuel Thibault]

Paul Durrant, on mer. 22 févr. 2017 11:03:37 +, wrote:
> libxendevicemodel has just been split out from libxc. From mini-os's
> point of view we don't care about the distinction, so keep things
> simple by just including libxendevicemodel if libxc is enabled.
> 
> Signed-off-by: Paul Durrant 
> Cc: Samuel Thibault 

Acked-by: Samuel Thibault 

> ---
>  Makefile | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Makefile b/Makefile
> index 74f2c31..ef8559b 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -134,6 +134,8 @@ APP_LDLIBS += 
> -L$(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/call -whole-archi
>  LIBS += $(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/call/libxencall.a
>  APP_LDLIBS += -L$(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/foreignmemory 
> -whole-archive -lxenforeignmemory -no-whole-archive
>  LIBS += 
> $(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/foreignmemory/libxenforeignmemory.a
> +APP_LDLIBS += -L$(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/devicemodel 
> -whole-archive -lxendevicemodel -no-whole-archive
> +LIBS += 
> $(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/devicemodel/libxendevicemodel.a
>  APP_LDLIBS += -L$(XEN_ROOT)/stubdom/libxc-$(MINIOS_TARGET_ARCH) 
> -whole-archive -lxenguest -lxenctrl -no-whole-archive
>  LIBS += $(XEN_ROOT)/stubdom/libxc-$(MINIOS_TARGET_ARCH)/libxenctrl.a
>  LIBS += $(XEN_ROOT)/stubdom/libxc-$(MINIOS_TARGET_ARCH)/libxenguest.a
> -- 
> 2.1.4
> 

-- 
Samuel
 Battery 1: charging, 90%, charging at zero rate - will never fully charge.
 -+- acpi - et pourtant, ca monte -+-

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

Re: [Xen-devel] [RFC PATCH v1 03/21] NUMA: Move arch specific NUMA code as common

[Julien Grall]

Hello Vijay,

On 22/02/17 10:08, Vijay Kilari wrote:

On Mon, Feb 20, 2017 at 6:17 PM, Julien Grall  wrote:

On 09/02/17 15:56, vijay.kil...@gmail.com wrote:

diff --git a/xen/common/numa.c b/xen/common/numa.c
index 59dcb63..13f147c 100644
--- a/xen/common/numa.c
+++ b/xen/common/numa.c
@@ -46,6 +46,61 @@ nodeid_t cpu_to_node[NR_CPUS] __read_mostly = {

 cpumask_t node_to_cpumask[MAX_NUMNODES] __read_mostly;

+int num_node_memblks;
+struct node node_memblk_range[NR_NODE_MEMBLKS];
+nodeid_t memblk_nodeid[NR_NODE_MEMBLKS];
+struct node nodes[MAX_NUMNODES] __initdata;
+
+int valid_numa_range(u64 start, u64 end, nodeid_t node)



I am not sure why you move this code in common code when it is not even used
in your series.

Yes, it is used only by x86 but code is generic. I will keep in x86 to
void further
comments on this function.


I was only asking why you move the code and not saying it should not be 
moved...


Anyway, I am ok with the move. But a bit more description in the commit 
message would have been appreciated.


Cheers,

Julien Grall

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

Re: [Xen-devel] [RFC PATCH v1 04/21] NUMA: Refactor generic and arch specific code of numa_setup

[Julien Grall]

Hello Vijay,

On 22/02/17 10:27, Vijay Kilari wrote:

On Mon, Feb 20, 2017 at 7:09 PM, Julien Grall  wrote:

On 09/02/17 15:56, vijay.kil...@gmail.com wrote:

@@ -145,13 +141,8 @@ void __init numa_initmem_init(unsigned long
start_pfn, unsigned long end_pfn)
 (u64)end_pfn << PAGE_SHIFT);
 }

-/* [numa=off] */
-static __init int numa_setup(char *opt)
+int __init arch_numa_setup(char *opt)



I don't understand why you split numa_setup. All the options look valid for
ARM.


OK.  This is all valid for arm, provided CONFIG_NUMA_EMU is implemented.
Can be moved to generic and for now we can keep CONFIG_NUMA_EMU
disabled for arm.


Why do you want to keep CONFIG_NUMA_EMU disabled on ARM? This is really 
useful to test NUMA code on non-NUMA platform.


Regards,

--
Julien Grall

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

Re: [Xen-devel] [RFC PATCH v1 06/21] ARM: NUMA: Parse CPU NUMA information

[Julien Grall]

Hello Vijay,

On 22/02/17 10:46, Vijay Kilari wrote:

On Mon, Feb 20, 2017 at 11:02 PM, Julien Grall  wrote:

On 09/02/17 15:56, vijay.kil...@gmail.com wrote:


From: Vijaya Kumar K 

Parse CPU node and fetch numa-node-id information.
For each node-id found, update nodemask_t mask.



A link to the bindings would have been useful...


Call numa_init() from setup_mm() with start and end
pfn of the complete ram..



s/.././



Signed-off-by: Vijaya Kumar K 
---
 xen/arch/arm/Makefile |  1 +
 xen/arch/arm/bootfdt.c|  8 ++---
 xen/arch/arm/dt_numa.c| 72
+++
 xen/arch/arm/numa.c   | 14 +
 xen/arch/arm/setup.c  |  3 ++
 xen/include/asm-arm/numa.h| 14 +
 xen/include/xen/device_tree.h |  4 +++
 7 files changed, 112 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index b5d7a19..7694485 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -50,6 +50,7 @@ obj-y += vtimer.o
 obj-y += vpsci.o
 obj-y += vuart.o
 obj-$(CONFIG_NUMA) += numa.o
+obj-$(CONFIG_NUMA) += dt_numa.o



I would prefer if we introduce a directly numa within arm. This would make
the root cleaner.


As it is very specific to DT, I have introduced in this file. ACPI is
implemented
in separate file. Common arm specific numa code is in numa.c file.


Sorry I meant separate directory not not "directly".

Regards,

--
Julien Grall

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

[Xen-devel] [distros-debian-squeeze test] 68599: tolerable trouble: broken/fail/pass

[Platform Team regression test user]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-i386-squeeze-netboot-pygrub 9 debian-di-install fail like 68561
 test-amd64-amd64-i386-squeeze-netboot-pygrub 9 debian-di-install fail like 
68561
 test-amd64-amd64-amd64-squeeze-netboot-pygrub 9 debian-di-install fail like 
68561
 test-amd64-i386-amd64-squeeze-netboot-pygrub 9 debian-di-install fail like 
68561

Tests which did not succeed, but are not blocking:
 build-arm64-pvops 2 hosts-allocate   broken never pass
 build-arm64   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   68561

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-squeeze-netboot-pygrubfail
 test-amd64-i386-amd64-squeeze-netboot-pygrub fail
 test-amd64-amd64-i386-squeeze-netboot-pygrub fail
 test-amd64-i386-i386-squeeze-netboot-pygrub  fail



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 v2] x86/VMX: sanitize VM86 TSS handling

[Jan Beulich]

>>> On 22.02.17 at 11:45,  wrote:
> On 17/02/17 12:03, Jan Beulich wrote:
>> @@ -4267,6 +4336,12 @@ static int hvmop_get_param(
>>  case HVM_PARAM_ACPI_S_STATE:
>>  a.value = d->arch.hvm_domain.is_s3_suspended ? 3 : 0;
>>  break;
>> +
>> +case HVM_PARAM_VM86_TSS:
>> +a.value = (uint32_t)d->arch.hvm_domain.params
>> +[HVM_PARAM_VM86_TSS_SIZED];
>> +break;
> 
> HVM_PARAM_VM86_TSS_SIZED needs to have VM86_TSS_UPDATED masked out on a
> read, or the guest and toolstack will observe a crazy size if they read
> the param back before CR0.PE is cleared.

Oops, of course. My mental note to do this must have gone lost
with the various other adjustments that were needed from v1.

> Otherwise, Reviewed-by: Andrew Cooper 

Thanks, Jan


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

Re: [Xen-devel] Python 3 bindings

[Wei Liu]

On Tue, Feb 21, 2017 at 02:03:00PM +0100, Marek Marczykowski-Górecki wrote:
> On Mon, Feb 20, 2017 at 05:18:44PM +, Wei Liu wrote:
> > On Fri, Feb 17, 2017 at 01:36:01PM +0100, Marek Marczykowski-Górecki wrote:
> > > Hi,
> > > 
> > > I'm adjusting python bindings to work on python3 too. This will require
> > > few #if in the code (to compile for both python2 and python3), but it
> > > isn't that bad. But there are some major changes in python3, which
> > > require some decision about the bindings API:
> > > 
> > > 1. Python3 has no longer separate 'int' and 'long' type - old 'long'
> > > type was renamed to 'int' (but on C-API level, it uses PyLong_*). I see
> > > two options:
> > >   - switch to PyLong_* everywhere, including python2 bindings - this
> > > makes the code much cleaner, but it is an API change in python2
> > >   - switch to PyLong_* only for python3 - this will introduce some
> > > #ifdefs, but python2 API will be unchanged
> > 
> > Could you be more specific? Like, provide a code snippet?
> 
> Here is compile tested only version:
> https://github.com/marmarek/xen/tree/python3
> 
> It uses PyLong_* only for python3, here is how it looks in code (I've
> skipped s/PyInt_/PyLongOrInt_/ for readability):
> 
> -8<-
> --- a/tools/python/xen/lowlevel/xc/xc.c
> +++ b/tools/python/xen/lowlevel/xc/xc.c
> @@ -34,6 +34,17 @@
>  
>  #define FLASK_CTX_LEN 1024
>  
> +/* Python 2 compatibility */
> +#if PY_VERSION_HEX >= 0x0300
> +#define PyLongOrInt_FromLong PyLong_FromLong
> +#define PyLongOrInt_Check PyLong_Check
> +#define PyLongOrInt_AsLong PyLong_AsLong
> +#else
> +#define PyLongOrInt_FromLong PyInt_FromLong
> +#define PyLongOrInt_Check PyInt_Check
> +#define PyLongOrInt_AsLong PyInt_AsLong
> +#endif
> +
>  static PyObject *xc_error_obj, *zero;
>  
>  typedef struct {
> --- a/tools/python/xen/lowlevel/xs/xs.c
> +++ b/tools/python/xen/lowlevel/xs/xs.c
> @@ -43,6 +43,14 @@
>  #define PKG "xen.lowlevel.xs"
>  #define CLS "xs"
>  
> +#if PY_VERSION_HEX < 0x0300
> +/* Python 2 compatibility */
> +#define PyLong_FromLong PyInt_FromLong
> +#undef PyLong_Check
> +#define PyLong_Check PyInt_Check
> +#define PyLong_AsLong PyInt_AsLong
> +#endif
> +
>  static PyObject *xs_error;
>  

If this is the recommended practice, then that's fine. I can't seem to
find such practice in https://docs.python.org/3/howto/cporting.html but
I'm no python binding expert.

BTW, I went through your python3 branch. It seems that some patches can
be submitted independently.


>  /** Python wrapper round an xs handle.
> -8<-
> 
> > 
> > > 
> > > 2. Python3 has no longer separate 'str' and 'unicode' type, new 'str' is
> > > the same as 'unicode' (PyUnicode_* at C-API level). For things not
> > > really unicode-aware, 'bytes' type should be used. On the other hand, in
> > > python2 'bytes' type was the same as 'str'.
> > > This affects various places, where in most cases 'bytes' type is
> > > appropriate (for example cpuid). But I'm not sure about xenstore paths -
> > > those should also be 'bytes', or maybe 'unicode' (which is implicitly
> > > using 'utf-8' encoding)? I think the only reason to use 'unicode' is
> > 
> > According to docs/txt/misc/xenstore.txt, paths should be ASCII
> > alphanumerics plus four punctuation characters. Not sure if this is
> > relevant to what you describe.
> 
> It's easy to make function accept both 'bytes' and 'unicode'. The
> question is what should be return type (read_watch, ls etc) - given
> limited character set used there, I'm in favor of 'unicode' - easier to
> handle, but we shouldn't hit any unicode decoding problems.
> Maybe the same should apply to path arguments (use 'unicode')? Most
> file-handling methods in python3 use 'unicode' for paths, if that
> matters.
> 

OK. Using unicode makes sense to me. Again, I'm no python expert and I
trust what you said. :-)

> > > convenience for API users - in python3 if you write 'some string' it
> > > will be unicode type, to create bytes data you need to write b'some
> > > string'.
> > > As for python2, it should definitely be still 'str'/'bytes' type.
> > > 
> > > There is one more little detail - build process. Here I'm going to
> > > follow popular standard - use $(PYTHON) variable - if that points to
> > > python3, build for python3. Actually this means no change in the current
> > > makefile. If someone want to build for both python2 and python3, will
> > > need to call the build twice - at packaging level.
> 
> -- 
> Best Regards,
> Marek Marczykowski-Górecki
> Invisible Things Lab
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?



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

Re: [Xen-devel] [PATCH] build: add --with-rundir option to configure

[Wei Liu]

On Wed, Feb 22, 2017 at 08:53:24AM +0100, Juergen Gross wrote:
> On 20/02/17 16:19, Andrew Cooper wrote:
> > On 20/02/17 14:43, Juergen Gross wrote:
> >> On 20/02/17 15:31, Wei Liu wrote:
> >>> On Thu, Feb 16, 2017 at 08:47:07AM +0100, Juergen Gross wrote:
>  There have been reports that Fedora 25 uses /run instead of /var/run.
> 
>  Add a --with-rundir option ito configure to be able to specify that
> >>> I've read this thread but I'm not sure if I need to take any action or
> >>> all the comments addressed -- especially the part about autoconf.
> >> Andrew, are you fine with my answer regarding autoconf? Or do you have
> >> some information regarding --runstatedir which could help?
> > 
> > Oh sorry.  Didn't realise I was blocking here.  I have no specific
> > information, other than the quick search I did.
> > 
> > Can't the future problem be worked around just with if autoconf version
> > < 2.70 ?
> 
> I don't think it is possible to add configure options other than
> --disable-*, --enable-*, --with-* or --without-* by other means than
> patching general.m4 of autoconf. I don't think we want to do that.
> 
> So the possibilities are:
> 
> 1. don't support /run instead of /var/run via configure
> 2. patch autoconf to support --runstatedir
> 3. take this patch adding support via --with-rundir and possibly
>switch over to --runstatedir when a new autoconf version is
>available

Option 3 but we need to have that for eternity. :-)

Wei.

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

Re: [Xen-devel] [RFC PATCH v1 08/21] ARM: NUMA: Parse NUMA distance information

[Vijay Kilari]

On Mon, Feb 20, 2017 at 11:58 PM, Julien Grall  wrote:
> Hello Vijay,
>
> On 09/02/17 15:57, vijay.kil...@gmail.com wrote:
>>
>> From: Vijaya Kumar K 
>>
>> Parse distance-matrix and fetch node distance information.
>> Store distance information in node_distance[].
>>
>> Signed-off-by: Vijaya Kumar K 
>> ---
>>  xen/arch/arm/dt_numa.c | 90
>> ++
>>  xen/arch/arm/numa.c| 19 +-
>>  xen/include/asm-arm/numa.h |  1 +
>>  3 files changed, 109 insertions(+), 1 deletion(-)
>>
>> diff --git a/xen/arch/arm/dt_numa.c b/xen/arch/arm/dt_numa.c
>> index fce9e67..8979612 100644
>> --- a/xen/arch/arm/dt_numa.c
>> +++ b/xen/arch/arm/dt_numa.c
>> @@ -28,6 +28,19 @@
>>
>>  nodemask_t numa_nodes_parsed;
>>  extern struct node node_memblk_range[NR_NODE_MEMBLKS];
>> +extern int _node_distance[MAX_NUMNODES * 2];
>> +extern int *node_distance;
>
>
> I don't like this idea of having _node_distance and node_distance. Looking
> at the code, I see little point to do that. You could just initialize
> node_distance with the correct value.
>
> Also the node distance can fit in u8, so you can save memory by using u8.

u8 might restrict the distance value
>
> Lastly, I am not sure why you pre-allocate the memory. The distance table.
> could be quite big.
ok. will do malloc
>
>> +
>> +static int numa_set_distance(u32 nodea, u32 nodeb, u32 distance)
>
>
> Please avoid the use of u32 in favor of uint32_t.
>
> Also, this function does not look very DT specific.
>
>> +{
>> +   if ( nodea >= MAX_NUMNODES || nodeb >= MAX_NUMNODES )
>> +   return -EINVAL;
>> +
>
>
> I would have expected some sanity check here.
>
>
>> +   _node_distance[(nodea * MAX_NUMNODES) + nodeb] = distance;
>> +   node_distance = &_node_distance[0];
>> +
>> +   return 0;
>> +}
>>
>>  /*
>>   * Even though we connect cpus to numa domains later in SMP
>> @@ -112,6 +125,66 @@ static int __init dt_numa_process_memory_node(const
>> void *fdt, int node,
>>  return 0;
>>  }
>>
>> +static int __init dt_numa_parse_distance_map(const void *fdt, int node,
>> + const char *name,
>> + u32 address_cells,
>> + u32 size_cells)
>> +{
>> +const struct fdt_property *prop;
>> +const __be32 *matrix;
>> +int entry_count, len, i;
>> +
>> +printk(XENLOG_INFO "NUMA: parsing numa-distance-map\n");
>> +
>> +prop = fdt_get_property(fdt, node, "distance-matrix", &len);
>> +if ( !prop )
>> +{
>> +printk(XENLOG_WARNING
>> +   "NUMA: No distance-matrix property in distance-map\n");
>> +
>> +return -EINVAL;
>> +}
>> +
>> +if ( len % sizeof(u32) != 0 )
>> +{
>> + printk(XENLOG_WARNING
>> +"distance-matrix in node is not a multiple of u32\n");
>> +
>> +return -EINVAL;
>> +}
>> +
>> +entry_count = len / sizeof(u32);
>> +if ( entry_count <= 0 )
>> +{
>> +printk(XENLOG_WARNING "NUMA: Invalid distance-matrix\n");
>> +
>> +return -EINVAL;
>> +}
>> +
>> +matrix = (const __be32 *)prop->data;
>> +for ( i = 0; i + 2 < entry_count; i += 3 )
>> +{
>> +u32 nodea, nodeb, distance;
>> +
>> +nodea = dt_read_number(matrix, 1);
>> +matrix++;
>> +nodeb = dt_read_number(matrix, 1);
>> +matrix++;
>> +distance = dt_read_number(matrix, 1);
>> +matrix++;
>> +
>> +numa_set_distance(nodea, nodeb, distance);
>
>
> What if numa_set_distance failed?

IMO, no need to fail numa. Should be set to default values for node_distance[].

>
>> +printk(XENLOG_INFO "NUMA:  distance[node%d -> node%d] = %d\n",
>> +   nodea, nodeb, distance);
>> +
>> +/* Set default distance of node B->A same as A->B */
>> +if ( nodeb > nodea )
>> +numa_set_distance(nodeb, nodea, distance);
>> +}
>> +
>> +return 0;
>> +}
>> +
>>  static int __init dt_numa_scan_cpu_node(const void *fdt, int node,
>>  const char *name, int depth,
>>  u32 address_cells, u32
>> size_cells,
>> @@ -136,6 +209,18 @@ static int __init dt_numa_scan_memory_node(const void
>> *fdt, int node,
>>  return 0;
>>  }
>>
>> +static int __init dt_numa_scan_distance_node(const void *fdt, int node,
>> + const char *name, int depth,
>> + u32 address_cells, u32
>> size_cells,
>> + void *data)
>> +{
>> +if ( device_tree_node_matches(fdt, node, "distance-map") )
>
>
> Similar to memory and cpu, the name is not fixed. What you want to look for
> is the compatible numa-distance-map-v1.
ok
>
>
>> +return dt_numa_parse_distance_map(fdt, node, name, address_cells,
>> +  size_cells);
>>

Re: [Xen-devel] Unshared IOMMU issues

[Julien Grall]

On 21/02/17 10:39, Oleksandr Tyshchenko wrote:

Hi, Julien.


Hi Oleksandr,


On Mon, Feb 20, 2017 at 10:31 AM, Julien Grall  wrote:

Hello Oleksandr,

On 02/17/2017 08:20 PM, Oleksandr Tyshchenko wrote:


Hi, all.

So, as I understand we have two possible solutions for the IOMMU page
table to be populated:
1.  When the first device is being assigned. Retrieve all mappings
from stage-2 table.
2.  When the domain is being created.

I would prefer the second variant.



I am happy with the second variant as long as IOMMU is not enabled by
default when the guest will have no device assigned.

OK.

Just to clarify.
We don't need to assign devices when creating domain (at the
iommu_domain_init() time).
We just need to have some knowledge about device assignment in general
(will the guest have assigned devices or won't) .
And only in case when the guest is going to have assigned devices we
will populate IOMMU page table (call iommu_construct()).
Right?


That's correct.

Cheers,

--
Julien Grall

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail REGR. vs. 59254
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail REGR. vs. 59254
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 13 guest-localmigrate fail REGR. 
vs. 59254
 test-amd64-amd64-xl-qemut-debianhvm-amd64 13 guest-localmigrate fail REGR. vs. 
59254
 test-armhf-armhf-xl   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-libvirt  6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-credit2   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-xsm   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-libvirt-xsm  6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-arndale   6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl-qemut-debianhvm-amd64 20 leak-check/check fail REGR. vs. 
59254

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds  6 xen-boot  fail REGR. vs. 59254
 test-amd64-amd64-xl-rtds  9 debian-installfail REGR. vs. 59254
 test-armhf-armhf-xl-vhd   6 xen-bootfail baseline untested
 test-armhf-armhf-libvirt-raw  6 xen-bootfail baseline untested
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 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

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-libvirt 12 migrate-support-checkfail   never pass
 build-arm64-xsm   5 xen-buildfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 build-arm64   5 xen-buildfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-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-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass

version targeted for testing:
 linux9763dd6f8160dc9cc239fc2427c8173073204457
baseline version:
 linux45820c294fe1b1a9df495d57f40585ef2d069a39

Last test of basis59254  2015-07-09 04:20:48 Z  594 days
Failing since 59348  2015-07-10 04:24:05 Z  593 days  290 attempts
Testing same since   105960  2017-02-21 19:54:18 Z0 days1 attempts


7638 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-pvops   

Re: [Xen-devel] [RFC PATCH v1 08/21] ARM: NUMA: Parse NUMA distance information

[Julien Grall]

Hello Vijay,

On 22/02/17 11:38, Vijay Kilari wrote:

On Mon, Feb 20, 2017 at 11:58 PM, Julien Grall  wrote:

Hello Vijay,

On 09/02/17 15:57, vijay.kil...@gmail.com wrote:


From: Vijaya Kumar K 

Parse distance-matrix and fetch node distance information.
Store distance information in node_distance[].

Signed-off-by: Vijaya Kumar K 
---
 xen/arch/arm/dt_numa.c | 90
++
 xen/arch/arm/numa.c| 19 +-
 xen/include/asm-arm/numa.h |  1 +
 3 files changed, 109 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/dt_numa.c b/xen/arch/arm/dt_numa.c
index fce9e67..8979612 100644
--- a/xen/arch/arm/dt_numa.c
+++ b/xen/arch/arm/dt_numa.c
@@ -28,6 +28,19 @@

 nodemask_t numa_nodes_parsed;
 extern struct node node_memblk_range[NR_NODE_MEMBLKS];
+extern int _node_distance[MAX_NUMNODES * 2];
+extern int *node_distance;



I don't like this idea of having _node_distance and node_distance. Looking
at the code, I see little point to do that. You could just initialize
node_distance with the correct value.

Also the node distance can fit in u8, so you can save memory by using u8.


u8 might restrict the distance value


The numa distance function returns an u8 and the common code rely on u8. 
So IHMO it is fine to restrict to u8.


If you want to keep u8 then please fix the rest of the code.

[...]


+numa_set_distance(nodea, nodeb, distance);



What if numa_set_distance failed?


IMO, no need to fail numa. Should be set to default values for node_distance[].


If you look at your implementation of numa_set_distance it returns an 
error if the nodea, nodeb are too big. So you should really check the

return an report an error. Because the DT is buggy.

[...]





+return dt_numa_parse_distance_map(fdt, node, name, address_cells,
+  size_cells);
+
+return 0;
+}
+
 int __init dt_numa_init(void)
 {
 int ret;
@@ -149,6 +234,11 @@ int __init dt_numa_init(void)

 ret = device_tree_for_each_node((void *)device_tree_flattened,
 dt_numa_scan_memory_node, NULL);
+if ( ret )
+return ret;
+
+ret = device_tree_for_each_node((void *)device_tree_flattened,
+dt_numa_scan_distance_node, NULL);

 return ret;
 }
diff --git a/xen/arch/arm/numa.c b/xen/arch/arm/numa.c
index 9a7f0bb..11d100b 100644
--- a/xen/arch/arm/numa.c
+++ b/xen/arch/arm/numa.c
@@ -22,14 +22,31 @@
 #include 
 #include 
 #include 
+#include 



Why did you add this include. I don't see any errno here.


+
+int _node_distance[MAX_NUMNODES * 2];
+int *node_distance;
+
+u8 __node_distance(nodeid_t a, nodeid_t b)
+{
+if ( !node_distance )
+return a == b ? 10 : 20;



Why does the 10/20 comes from?


That is default distance value.


From where? Please give a link to the doc.

Regards,

--
Julien Grall

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

Re: [Xen-devel] Python 3 bindings

[Marek Marczykowski-Górecki]

On Wed, Feb 22, 2017 at 11:34:16AM +, Wei Liu wrote:
> On Tue, Feb 21, 2017 at 02:03:00PM +0100, Marek Marczykowski-Górecki wrote:
> > On Mon, Feb 20, 2017 at 05:18:44PM +, Wei Liu wrote:
> > > On Fri, Feb 17, 2017 at 01:36:01PM +0100, Marek Marczykowski-Górecki 
> > > wrote:
> > > > Hi,
> > > > 
> > > > I'm adjusting python bindings to work on python3 too. This will require
> > > > few #if in the code (to compile for both python2 and python3), but it
> > > > isn't that bad. But there are some major changes in python3, which
> > > > require some decision about the bindings API:
> > > > 
> > > > 1. Python3 has no longer separate 'int' and 'long' type - old 'long'
> > > > type was renamed to 'int' (but on C-API level, it uses PyLong_*). I see
> > > > two options:
> > > >   - switch to PyLong_* everywhere, including python2 bindings - this
> > > > makes the code much cleaner, but it is an API change in python2
> > > >   - switch to PyLong_* only for python3 - this will introduce some
> > > > #ifdefs, but python2 API will be unchanged
> > > 
> > > Could you be more specific? Like, provide a code snippet?
> > 
> > Here is compile tested only version:
> > https://github.com/marmarek/xen/tree/python3
> > 
> > It uses PyLong_* only for python3, here is how it looks in code (I've
> > skipped s/PyInt_/PyLongOrInt_/ for readability):
> > 
> > -8<-
> > --- a/tools/python/xen/lowlevel/xc/xc.c
> > +++ b/tools/python/xen/lowlevel/xc/xc.c
> > @@ -34,6 +34,17 @@
> >  
> >  #define FLASK_CTX_LEN 1024
> >  
> > +/* Python 2 compatibility */
> > +#if PY_VERSION_HEX >= 0x0300
> > +#define PyLongOrInt_FromLong PyLong_FromLong
> > +#define PyLongOrInt_Check PyLong_Check
> > +#define PyLongOrInt_AsLong PyLong_AsLong
> > +#else
> > +#define PyLongOrInt_FromLong PyInt_FromLong
> > +#define PyLongOrInt_Check PyInt_Check
> > +#define PyLongOrInt_AsLong PyInt_AsLong
> > +#endif
> > +
> >  static PyObject *xc_error_obj, *zero;
> >  
> >  typedef struct {
> > --- a/tools/python/xen/lowlevel/xs/xs.c
> > +++ b/tools/python/xen/lowlevel/xs/xs.c
> > @@ -43,6 +43,14 @@
> >  #define PKG "xen.lowlevel.xs"
> >  #define CLS "xs"
> >  
> > +#if PY_VERSION_HEX < 0x0300
> > +/* Python 2 compatibility */
> > +#define PyLong_FromLong PyInt_FromLong
> > +#undef PyLong_Check
> > +#define PyLong_Check PyInt_Check
> > +#define PyLong_AsLong PyInt_AsLong
> > +#endif
> > +
> >  static PyObject *xs_error;
> >  
> 
> If this is the recommended practice, then that's fine. I can't seem to
> find such practice in https://docs.python.org/3/howto/cporting.html but
> I'm no python binding expert.

"In the C-API, PyInt_* functions are replaced by their PyLong_*
equivalents."

> BTW, I went through your python3 branch. It seems that some patches can
> be submitted independently.

Yes, I've tried to separate cleanup commits from actual python3 support.

> >  /** Python wrapper round an xs handle.
> > -8<-
> > 
> > > 
> > > > 
> > > > 2. Python3 has no longer separate 'str' and 'unicode' type, new 'str' is
> > > > the same as 'unicode' (PyUnicode_* at C-API level). For things not
> > > > really unicode-aware, 'bytes' type should be used. On the other hand, in
> > > > python2 'bytes' type was the same as 'str'.
> > > > This affects various places, where in most cases 'bytes' type is
> > > > appropriate (for example cpuid). But I'm not sure about xenstore paths -
> > > > those should also be 'bytes', or maybe 'unicode' (which is implicitly
> > > > using 'utf-8' encoding)? I think the only reason to use 'unicode' is
> > > 
> > > According to docs/txt/misc/xenstore.txt, paths should be ASCII
> > > alphanumerics plus four punctuation characters. Not sure if this is
> > > relevant to what you describe.
> > 
> > It's easy to make function accept both 'bytes' and 'unicode'. The
> > question is what should be return type (read_watch, ls etc) - given
> > limited character set used there, I'm in favor of 'unicode' - easier to
> > handle, but we shouldn't hit any unicode decoding problems.
> > Maybe the same should apply to path arguments (use 'unicode')? Most
> > file-handling methods in python3 use 'unicode' for paths, if that
> > matters.
> > 
> 
> OK. Using unicode makes sense to me. Again, I'm no python expert and I
> trust what you said. :-)

Ok, I'll adjust patches to return unicode paths.

Then test them and actually send here :)

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?


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

[Xen-devel] [OSSTEST PATCH 3/4] html output: ms-flights-summary: Generate link to flight logs directory

[Ian Jackson]

Make the flight number be a link to the unpublished flight logs.

Signed-off-by: Ian Jackson 
---
 ms-flights-summary | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/ms-flights-summary b/ms-flights-summary
index 78f8675..10ad6e5 100755
--- a/ms-flights-summary
+++ b/ms-flights-summary
@@ -435,6 +435,7 @@ printf("\n");
 my $first = 1;
 foreach my $f (sort keys %flights) {
 my $fi = $flights{$f};
+my $furl = "$c{ReportHtmlUnpubBaseUrl}/$f/";
 
 $alt = 0;
 
@@ -442,7 +443,8 @@ foreach my $f (sort keys %flights) {
 print (" \n") if !$first;
 $first = 0;
 print("\n");
-flight_hdr("Flight: $f [$fi->{Branch} $fi->{Intended}]");
+flight_hdr_raw("Flight: $f".
+  encode_entities(" [$fi->{Branch} $fi->{Intended}]"));
 flight_hdr("Common info (active jobs only): $fi->{Info}") if $fi->{Info};
 flight_hdr("Started: ".fmttime($fi->{Started}));
 flight_hdr("Current phase ($fi->{UnqueuedJobs}/$fi->{NrJobs} jobs)".
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 1/4] html output: ReportHtmlUnpubBaseUrl: New config variable

[Ian Jackson]

This allows us to generate private urls for unpublished flights.  This
will be useful for links from the ongoing flights summary - since,
naturally, none of those logs are published yet.

The URLs will be of more limited use; the exact usefulness will depend
on the deployment.

If no separate Unpub url is specified, simply use the Pub one.

Signed-off-by: Ian Jackson 
---
 Osstest.pm| 2 ++
 production-config | 1 +
 2 files changed, 3 insertions(+)

diff --git a/Osstest.pm b/Osstest.pm
index 4ebd922..a78728c 100644
--- a/Osstest.pm
+++ b/Osstest.pm
@@ -237,6 +237,8 @@ sub readglobalconfig () {
 $c{WebspaceCommon} ||= 'osstest/';
 $c{WebspaceLog} ||= '/var/log/apache2/access.log';
 
+$c{ReportHtmlUnpubBaseUrl} ||= $c{ReportHtmlPubBaseUrl};
+
 $c{OverlayLocal} ||= "overlay-local";
 $c{GuestDebianSuite} ||= $c{DebianSuite};
 
diff --git a/production-config b/production-config
index 9bc2dc8..a95e243 100644
--- a/production-config
+++ b/production-config
@@ -54,6 +54,7 @@ HttpProxy http://cache:3128/
 PubBaseUrl http://logs.test-lab.xenproject.org/osstest
 ReportHtmlPubBaseUrl="$c{PubBaseUrl}/logs"
 ResultsHtmlPubBaseUrl="$c{PubBaseUrl}/results"
+ReportHtmlUnpubBaseUrl="http://osstest/~osstest/pub/logs/";
 
 Publish osstest@www:/var/www/osstest
 GlobalLockDir /home/osstest/testing.git
-- 
2.1.4


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

Re: [Xen-devel] Unshared IOMMU issues

[Oleksandr Tyshchenko]

On Wed, Feb 22, 2017 at 1:39 PM, Julien Grall  wrote:
> On 21/02/17 10:39, Oleksandr Tyshchenko wrote:
>>
>> Hi, Julien.

Hi, Julien, all.

>
>
> Hi Oleksandr,
>
>> On Mon, Feb 20, 2017 at 10:31 AM, Julien Grall 
>> wrote:
>>>
>>> Hello Oleksandr,
>>>
>>> On 02/17/2017 08:20 PM, Oleksandr Tyshchenko wrote:


 Hi, all.

 So, as I understand we have two possible solutions for the IOMMU page
 table to be populated:
 1.  When the first device is being assigned. Retrieve all mappings
 from stage-2 table.
 2.  When the domain is being created.

 I would prefer the second variant.
>>>
>>>
>>>
>>> I am happy with the second variant as long as IOMMU is not enabled by
>>> default when the guest will have no device assigned.
>>
>> OK.
>>
>> Just to clarify.
>> We don't need to assign devices when creating domain (at the
>> iommu_domain_init() time).
>> We just need to have some knowledge about device assignment in general
>> (will the guest have assigned devices or won't) .
>> And only in case when the guest is going to have assigned devices we
>> will populate IOMMU page table (call iommu_construct()).
>> Right?
>
>
> That's correct.

Thank you.

>
> Cheers,
>
> --
> Julien Grall



-- 
Regards,

Oleksandr Tyshchenko

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

[Xen-devel] [OSSTEST PATCH 4/4] html output: ms-flights-summary: Generate link to job logs directory

[Ian Jackson]

Make each job name in the detailed tables be a link to the
(unpublished) logs for that job.

Requested-by: Roger Pau Monné 
Signed-off-by: Ian Jackson 
---
 ms-flights-summary | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/ms-flights-summary b/ms-flights-summary
index 10ad6e5..0e5cd4d 100755
--- a/ms-flights-summary
+++ b/ms-flights-summary
@@ -315,7 +315,12 @@ sub do_one_job() {
 
 $tag = "b" if $info->{Anon} && currently_running($info);
 
-cell(encode_entities($job), undef, undef, $tag);
+my $jobcell = encode_entities($job);
+if ($fl) {
+   my $jurl = "$c{ReportHtmlUnpubBaseUrl}/$fl/$job/";
+   $jobcell = "".$jobcell."";
+}
+cell($jobcell, undef, undef, $tag);
 
 # Anonymous/rogue jobs may not have a flight or status
 if ($fl && $status) {
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 2/4] html output: ms-flights-summary: Break out flight_hdr_raw

[Ian Jackson]

Will will want this in a moment.  For now, no functional change.

Signed-off-by: Ian Jackson 
---
 ms-flights-summary | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/ms-flights-summary b/ms-flights-summary
index 7981e44..78f8675 100755
--- a/ms-flights-summary
+++ b/ms-flights-summary
@@ -272,11 +272,15 @@ sub cols_hdr() {
 printf("\n");
 }
 
-sub flight_hdr($) {
-my $text = encode_entities(shift);
+sub flight_hdr_raw($) {
+my ($text) = @_;
 printf("$text\n", scalar @cols);
 }
 
+sub flight_hdr($) {
+flight_hdr_raw(encode_entities(shift));
+}
+
 sub cell($;$$$) {
 my ($text,$colourattr,$fontattr,$tag) = @_;
 $text //= '';
-- 
2.1.4


___
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]

> 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 v3 1/2] libxl: replace deprecated readdir_r() with readdir()

[George Dunlap]

On Fri, Jun 3, 2016 at 5:50 PM, Chris Patterson  wrote:
> From: Chris Patterson 
>
> Replace the usage of readdir_r() with readdir() to address a
> compilation error under glibc due to the deprecation of readdir_r
> for their next release (2.24) [1, 2].
>
> Remove code specific to usage of readdir_r which is no longer required,
> such as zalloc_dirent().
>
> --
>
> From the GNU libc manual [3]:
> "
>  It is expected that future versions of POSIX will obsolete readdir_r and
>  mandate the level of thread safety for readdir which is provided by the
>  GNU C Library and other implementations today.
> "
>
> There is a filed bug in the Austin Group Defect Tracker [4]  in which 'dalias'
> proposes (in comment 0001632) that:
> "
>I would like to propose an alternate solution. For readdir, replace the 
> text:
> "The readdir() function need not be thread-safe."
>with:
> "If multiple threads call the readdir() function with the same directory
> stream argument and without synchronization to preclude simultaneous
> access, then the behavior is undefined."
>
>With this change, the clunky readdir_r function is no longer needed or
>useful, and should probably be deprecated. As the only reasonable way
>to meet the implementation requirements for readdir is to have the dirent
>buffer in the DIR structure, this change should not require any change to
>existing implementations.
> "
>
> [1] https://sourceware.org/ml/libc-alpha/2016-02/msg00093.html
> [2] https://sourceware.org/bugzilla/show_bug.cgi?id=19056
> [3] 
> https://www.gnu.org/software/libc/manual/html_node/Reading_002fClosing-Directory.html
> [4] http://austingroupbugs.net/view.php?id=696
>
> Signed-off-by: Chris Patterson 

Jan,

These patches should be backported to the 4.6 branch (and earlier?) as well.

The commits are b9daff9 and c2a1786 if you want to cherry-pick them.
(b9daff9 doesn't apply quite cleanly because libxl_pvusb.c doesn't
exist).

 -George

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

Re: [Xen-devel] [PATCH 1/2] Add libxendevicemodel to rpath-link

[Ian Jackson]

Paul Durrant writes ("[PATCH 1/2] Add libxendevicemodel to rpath-link"):
> libxenctrl now depends on this library

FAOD, this and the next one look like patches against qemu-trad.  It's
normally a good idea to state this somewhere :-).

There is, AIUI, no forward/backward compatibility provided (at least
not for qemu-trad).  That is fine, but it means that the qemu-trad
patches need to be pushed first, and then the QEMU_TAG update needs to
be folded into relevant xen.git commit.  So when the series is ready
to commit, committers need to coordinate.

Anyway, both patches:

Acked-by: Ian Jackson 

Ian.

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

Re: [Xen-devel] [PATCH 1/2] Add libxendevicemodel to rpath-link

[Paul Durrant]

> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: 22 February 2017 12:09
> To: Paul Durrant 
> Cc: xen-de...@lists.xenproject.org
> Subject: Re: [PATCH 1/2] Add libxendevicemodel to rpath-link
> 
> Paul Durrant writes ("[PATCH 1/2] Add libxendevicemodel to rpath-link"):
> > libxenctrl now depends on this library
> 
> FAOD, this and the next one look like patches against qemu-trad.  It's
> normally a good idea to state this somewhere :-).

Sorry, there was meant to be a patch #0 for that.

> 
> There is, AIUI, no forward/backward compatibility provided (at least
> not for qemu-trad).  That is fine, but it means that the qemu-trad
> patches need to be pushed first, and then the QEMU_TAG update needs to
> be folded into relevant xen.git commit.  So when the series is ready
> to commit, committers need to coordinate.
> 

Indeed they do. I'll send the libxl series with URLs and tags pointing at my 
repos on xenbits and mention in the patch header that these need to be 
appropriately substituted.

> Anyway, both patches:
> 
> Acked-by: Ian Jackson 
> 

Thanks,

  Paul

> Ian.

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

Re: [Xen-devel] [PATCH v2 3/5] xenstore: add support for changing log functionality dynamically

[Wei Liu]

On Tue, Feb 21, 2017 at 04:07:35PM +0100, Juergen Gross wrote:
[...]
>  static bool recovery = true;
>  static int reopen_log_pipe[2];
>  static int reopen_log_pipe0_pollfd_idx = -1;
> -static char *tracefile = NULL;
> +char *tracefile = NULL;
>  static TDB_CONTEXT *tdb_ctx = NULL;
>  static bool trigger_talloc_report = false;
>  
> @@ -205,12 +205,17 @@ static void trigger_reopen_log(int signal 
> __attribute__((unused)))
>   dummy = write(reopen_log_pipe[1], &c, 1);
>  }
>  
> +void close_log(void)
> +{
> + if (tracefd > 0)

tracefd >= 0

I think this is a bug in the original code though.

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

Re: [Xen-devel] [PATCH v2 2/5] xenstore: enhance control command support

[Wei Liu]

On Tue, Feb 21, 2017 at 04:07:34PM +0100, Juergen Gross wrote:
> The Xenstore protocol supports the XS_CONTROL command for triggering
> various actions in the Xenstore daemon. Enhance that support by using
> a command table and adding a help function. Move all the XS_CONTROL
> related code to a new source file xenstored_control.c.
> 
> Support multiple control commands in the associated xenstore-control
> program used to issue XS_CONTROL commands.
> 
> Signed-off-by: Juergen Gross 

Can you please break the refactoring and enhancement into two patches.
That would be easier for me to review.

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

Re: [Xen-devel] [PATCH v2 1/5] xenstore: rename XS_DEBUG wire command

[Wei Liu]

On Tue, Feb 21, 2017 at 04:07:33PM +0100, Juergen Gross wrote:
> In preparation to support other than pure debug functionality via the
> Xenstore XS_DEBUG wire command rename it to XS_CONTROL and make
> XS_DEBUG an alias of it.
> 
> Add an alias xs_control_command for the associated xs_debug_command,
> too.
> 
> Signed-off-by: Juergen Gross 
> ---
>  tools/xenstore/include/xenstore.h | 2 +-
>  tools/xenstore/xenstored_core.c   | 8 
>  tools/xenstore/xs.c   | 7 +++
>  xen/include/public/io/xs_wire.h   | 3 ++-
>  4 files changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/tools/xenstore/include/xenstore.h 
> b/tools/xenstore/include/xenstore.h
> index 0d12c39..66bb9ed 100644
> --- a/tools/xenstore/include/xenstore.h
> +++ b/tools/xenstore/include/xenstore.h
> @@ -262,9 +262,9 @@ bool xs_path_is_subpath(const char *parent, const char 
> *child);
>   */
>  bool xs_is_domain_introduced(struct xs_handle *h, unsigned int domid);
>  
> -/* Only useful for DEBUG versions */
>  char *xs_debug_command(struct xs_handle *h, const char *cmd,
>  void *data, unsigned int len);
> +#define xs_control_command xs_debug_command
>  

Should be the other way around?

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

Re: [Xen-devel] [PATCH v2 4/5] xenstore: make memory report available via XS_CONTROL

[Wei Liu]

On Tue, Feb 21, 2017 at 04:07:36PM +0100, Juergen Gross wrote:
> Add a XS_CONTROL command to xenstored for doing a talloc report to a
> file. Right now this is supported by specifying a command line option
> when starting xenstored and sending a signal to the daemon to trigger
> the report.
> 
> To dump the report to the standard log file call:
> 
> xenstore-control memreport
> 
> To dump the report to a new file call:
> 
> xenstore-control memreport 
> 
> Signed-off-by: Juergen Gross 
> ---
>  tools/xenstore/xenstored_control.c | 36 
>  tools/xenstore/xenstored_core.c|  2 +-
>  tools/xenstore/xenstored_core.h|  1 +
>  3 files changed, 38 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/xenstore/xenstored_control.c 
> b/tools/xenstore/xenstored_control.c
> index c3587ad..b4ec6ce 100644
> --- a/tools/xenstore/xenstored_control.c
> +++ b/tools/xenstore/xenstored_control.c
> @@ -76,6 +76,41 @@ static int do_control_logfile(void *ctx, struct connection 
> *conn,
>   return 0;
>  }
>  
> +static int do_control_memreport(void *ctx, struct connection *conn,
> + char **vec, int num)
> +{
> + FILE *fp;
> + int fd;
> +
> + if (num > 1)
> + return EINVAL;
> +
> + if (num == 0) {
> + if (tracefd < 0) {
> + if (!tracefile)
> + return EBADF;
> + fp = fopen(tracefile, "a");
> + } else {
> + fd = dup(tracefd);

Why dup() the fd? Is it because you want to avoid tracefd becomes
invalid under your feet?

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

Re: [Xen-devel] [PATCH v2 1/5] xenstore: rename XS_DEBUG wire command

[Juergen Gross]

On 22/02/17 13:36, Wei Liu wrote:
> On Tue, Feb 21, 2017 at 04:07:33PM +0100, Juergen Gross wrote:
>> In preparation to support other than pure debug functionality via the
>> Xenstore XS_DEBUG wire command rename it to XS_CONTROL and make
>> XS_DEBUG an alias of it.
>>
>> Add an alias xs_control_command for the associated xs_debug_command,
>> too.
>>
>> Signed-off-by: Juergen Gross 
>> ---
>>  tools/xenstore/include/xenstore.h | 2 +-
>>  tools/xenstore/xenstored_core.c   | 8 
>>  tools/xenstore/xs.c   | 7 +++
>>  xen/include/public/io/xs_wire.h   | 3 ++-
>>  4 files changed, 10 insertions(+), 10 deletions(-)
>>
>> diff --git a/tools/xenstore/include/xenstore.h 
>> b/tools/xenstore/include/xenstore.h
>> index 0d12c39..66bb9ed 100644
>> --- a/tools/xenstore/include/xenstore.h
>> +++ b/tools/xenstore/include/xenstore.h
>> @@ -262,9 +262,9 @@ bool xs_path_is_subpath(const char *parent, const char 
>> *child);
>>   */
>>  bool xs_is_domain_introduced(struct xs_handle *h, unsigned int domid);
>>  
>> -/* Only useful for DEBUG versions */
>>  char *xs_debug_command(struct xs_handle *h, const char *cmd,
>> void *data, unsigned int len);
>> +#define xs_control_command xs_debug_command
>>  
> 
> Should be the other way around?
> 

I did it that way to keep the xs_debug_command symbol in the library.
Otherwise someone using that function would have to rebuild.


Juergen

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

Re: [Xen-devel] [PATCH v2 2/5] xenstore: enhance control command support

[Juergen Gross]

On 22/02/17 13:36, Wei Liu wrote:
> On Tue, Feb 21, 2017 at 04:07:34PM +0100, Juergen Gross wrote:
>> The Xenstore protocol supports the XS_CONTROL command for triggering
>> various actions in the Xenstore daemon. Enhance that support by using
>> a command table and adding a help function. Move all the XS_CONTROL
>> related code to a new source file xenstored_control.c.
>>
>> Support multiple control commands in the associated xenstore-control
>> program used to issue XS_CONTROL commands.
>>
>> Signed-off-by: Juergen Gross 
> 
> Can you please break the refactoring and enhancement into two patches.
> That would be easier for me to review.
> 

Okay.


Juergen

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

Re: [Xen-devel] [PATCH v2 3/5] xenstore: add support for changing log functionality dynamically

[Juergen Gross]

On 22/02/17 13:36, Wei Liu wrote:
> On Tue, Feb 21, 2017 at 04:07:35PM +0100, Juergen Gross wrote:
> [...]
>>  static bool recovery = true;
>>  static int reopen_log_pipe[2];
>>  static int reopen_log_pipe0_pollfd_idx = -1;
>> -static char *tracefile = NULL;
>> +char *tracefile = NULL;
>>  static TDB_CONTEXT *tdb_ctx = NULL;
>>  static bool trigger_talloc_report = false;
>>  
>> @@ -205,12 +205,17 @@ static void trigger_reopen_log(int signal 
>> __attribute__((unused)))
>>  dummy = write(reopen_log_pipe[1], &c, 1);
>>  }
>>  
>> +void close_log(void)
>> +{
>> +if (tracefd > 0)
> 
> tracefd >= 0
> 
> I think this is a bug in the original code though.
> 

Okay, so I'll send another patch to correct this.


Juergen

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

Re: [Xen-devel] [PATCH v2 1/5] xenstore: rename XS_DEBUG wire command

[Wei Liu]

On Wed, Feb 22, 2017 at 01:40:42PM +0100, Juergen Gross wrote:
> On 22/02/17 13:36, Wei Liu wrote:
> > On Tue, Feb 21, 2017 at 04:07:33PM +0100, Juergen Gross wrote:
> >> In preparation to support other than pure debug functionality via the
> >> Xenstore XS_DEBUG wire command rename it to XS_CONTROL and make
> >> XS_DEBUG an alias of it.
> >>
> >> Add an alias xs_control_command for the associated xs_debug_command,
> >> too.
> >>
> >> Signed-off-by: Juergen Gross 
> >> ---
> >>  tools/xenstore/include/xenstore.h | 2 +-
> >>  tools/xenstore/xenstored_core.c   | 8 
> >>  tools/xenstore/xs.c   | 7 +++
> >>  xen/include/public/io/xs_wire.h   | 3 ++-
> >>  4 files changed, 10 insertions(+), 10 deletions(-)
> >>
> >> diff --git a/tools/xenstore/include/xenstore.h 
> >> b/tools/xenstore/include/xenstore.h
> >> index 0d12c39..66bb9ed 100644
> >> --- a/tools/xenstore/include/xenstore.h
> >> +++ b/tools/xenstore/include/xenstore.h
> >> @@ -262,9 +262,9 @@ bool xs_path_is_subpath(const char *parent, const char 
> >> *child);
> >>   */
> >>  bool xs_is_domain_introduced(struct xs_handle *h, unsigned int domid);
> >>  
> >> -/* Only useful for DEBUG versions */
> >>  char *xs_debug_command(struct xs_handle *h, const char *cmd,
> >>   void *data, unsigned int len);
> >> +#define xs_control_command xs_debug_command
> >>  
> > 
> > Should be the other way around?
> > 
> 
> I did it that way to keep the xs_debug_command symbol in the library.
> Otherwise someone using that function would have to rebuild.
> 

But then there is no xs_control_command symbol now.

I would just have two functions. xs_debug_command should be implemented
with xs_control_command (plus some extra check to only allow certain
behaviours if you fancy that).

> 
> Juergen

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

Re: [Xen-devel] [PATCH v2 4/5] xenstore: make memory report available via XS_CONTROL

[Juergen Gross]

On 22/02/17 13:36, Wei Liu wrote:
> On Tue, Feb 21, 2017 at 04:07:36PM +0100, Juergen Gross wrote:
>> Add a XS_CONTROL command to xenstored for doing a talloc report to a
>> file. Right now this is supported by specifying a command line option
>> when starting xenstored and sending a signal to the daemon to trigger
>> the report.
>>
>> To dump the report to the standard log file call:
>>
>> xenstore-control memreport
>>
>> To dump the report to a new file call:
>>
>> xenstore-control memreport 
>>
>> Signed-off-by: Juergen Gross 
>> ---
>>  tools/xenstore/xenstored_control.c | 36 
>>  tools/xenstore/xenstored_core.c|  2 +-
>>  tools/xenstore/xenstored_core.h|  1 +
>>  3 files changed, 38 insertions(+), 1 deletion(-)
>>
>> diff --git a/tools/xenstore/xenstored_control.c 
>> b/tools/xenstore/xenstored_control.c
>> index c3587ad..b4ec6ce 100644
>> --- a/tools/xenstore/xenstored_control.c
>> +++ b/tools/xenstore/xenstored_control.c
>> @@ -76,6 +76,41 @@ static int do_control_logfile(void *ctx, struct 
>> connection *conn,
>>  return 0;
>>  }
>>  
>> +static int do_control_memreport(void *ctx, struct connection *conn,
>> +char **vec, int num)
>> +{
>> +FILE *fp;
>> +int fd;
>> +
>> +if (num > 1)
>> +return EINVAL;
>> +
>> +if (num == 0) {
>> +if (tracefd < 0) {
>> +if (!tracefile)
>> +return EBADF;
>> +fp = fopen(tracefile, "a");
>> +} else {
>> +fd = dup(tracefd);
> 
> Why dup() the fd? Is it because you want to avoid tracefd becomes
> invalid under your feet?
> 

I want to be able to fclose() to get rid of the stream resources without
closing the log file.


Juergen

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

[Xen-devel] Failing to set up serial console for an s32v234-evb board (ARMv8)

[Johannes . 3 . Horn]

Hi
I'm writing my master thesis about using hypervisors on automotive high 
performance plattforms. As a part of my work for the thesis I'm trying to 
set up xen on a s32v234-evb (ARMv8) board using u-boot 2016.01. But I 
can't find a way of getting any output after u-boot try's to start the xen 
kernel.

If I boot to the kernel which will be used as dom0 the console is working 
fine and I im able to use the board. Following the xen serial console wiki 
page I build following xen bootargs: "sync_console console=com1 
com1=115200,8n1,0x40053000,23 earlyprintk=xen dom0_mem=128M" as "dmesg | 
grep tty" returned 
[ 0.488454] 40053000.serial: ttyLF0 at MMIO 0x40053000 (irq = 23, 
base_baud = 416) is a FSL_LINFLEX
[ 2.445563] console [ttyLF0] enabled
[ 2.457893] 400bc000.serial: ttyLF1 at MMIO 0x400bc000 (irq = 36, 
base_baud = 416) is a FSL_LINFLEX

I also tryed to use "sync_console console=dtuart 
dtuart=/soc/aips-bus@4000/serial@4005300 dom0_mem=128M" and 
"sync_console console=dtuart dtuart=serial0 dom0_mem=128M" as my dtb 
contains an alias for the first to serial0

The serial interface is defined as shown below within the dtb

=> fdt list /soc/aips-bus@4000/serial@40053000
serial@40053000 {
compatible = "fsl,s32v234-linflexuart";
reg = <0x 0x40053000 0x 0x1000>;
interrupts = <0x 0x003b 0x0001>;
clocks = <0x0002 0x0073 0x0002 0x0074>;
clock-names = "lin", "ipg";
dmas = <0x0006 0x 0x0014 0x0006 0x 
0x0013>;
dma-names = "rx", "tx";
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <0x0008>;
};

Mit freundlichen Grüßen / Best regards,
Johannes Horn
___
Johannes Horn
Continental Automotive GmbH
Corporate Systems & Technology

E-Mail: johannes03.h...@continental-corporation.com___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 1/5] xenstore: rename XS_DEBUG wire command

[Juergen Gross]

On 22/02/17 13:43, Wei Liu wrote:
> On Wed, Feb 22, 2017 at 01:40:42PM +0100, Juergen Gross wrote:
>> On 22/02/17 13:36, Wei Liu wrote:
>>> On Tue, Feb 21, 2017 at 04:07:33PM +0100, Juergen Gross wrote:
 In preparation to support other than pure debug functionality via the
 Xenstore XS_DEBUG wire command rename it to XS_CONTROL and make
 XS_DEBUG an alias of it.

 Add an alias xs_control_command for the associated xs_debug_command,
 too.

 Signed-off-by: Juergen Gross 
 ---
  tools/xenstore/include/xenstore.h | 2 +-
  tools/xenstore/xenstored_core.c   | 8 
  tools/xenstore/xs.c   | 7 +++
  xen/include/public/io/xs_wire.h   | 3 ++-
  4 files changed, 10 insertions(+), 10 deletions(-)

 diff --git a/tools/xenstore/include/xenstore.h 
 b/tools/xenstore/include/xenstore.h
 index 0d12c39..66bb9ed 100644
 --- a/tools/xenstore/include/xenstore.h
 +++ b/tools/xenstore/include/xenstore.h
 @@ -262,9 +262,9 @@ bool xs_path_is_subpath(const char *parent, const char 
 *child);
   */
  bool xs_is_domain_introduced(struct xs_handle *h, unsigned int domid);
  
 -/* Only useful for DEBUG versions */
  char *xs_debug_command(struct xs_handle *h, const char *cmd,
   void *data, unsigned int len);
 +#define xs_control_command xs_debug_command
  
>>>
>>> Should be the other way around?
>>>
>>
>> I did it that way to keep the xs_debug_command symbol in the library.
>> Otherwise someone using that function would have to rebuild.
>>
> 
> But then there is no xs_control_command symbol now.
> 
> I would just have two functions. xs_debug_command should be implemented
> with xs_control_command (plus some extra check to only allow certain
> behaviours if you fancy that).

Okay, if you like that better.


Juergen


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

Re: [Xen-devel] [PATCH v2 4/5] xenstore: make memory report available via XS_CONTROL

[Wei Liu]

On Wed, Feb 22, 2017 at 01:43:27PM +0100, Juergen Gross wrote:
> On 22/02/17 13:36, Wei Liu wrote:
> > On Tue, Feb 21, 2017 at 04:07:36PM +0100, Juergen Gross wrote:
> >> Add a XS_CONTROL command to xenstored for doing a talloc report to a
> >> file. Right now this is supported by specifying a command line option
> >> when starting xenstored and sending a signal to the daemon to trigger
> >> the report.
> >>
> >> To dump the report to the standard log file call:
> >>
> >> xenstore-control memreport
> >>
> >> To dump the report to a new file call:
> >>
> >> xenstore-control memreport 
> >>
> >> Signed-off-by: Juergen Gross 
> >> ---
> >>  tools/xenstore/xenstored_control.c | 36 
> >> 
> >>  tools/xenstore/xenstored_core.c|  2 +-
> >>  tools/xenstore/xenstored_core.h|  1 +
> >>  3 files changed, 38 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/tools/xenstore/xenstored_control.c 
> >> b/tools/xenstore/xenstored_control.c
> >> index c3587ad..b4ec6ce 100644
> >> --- a/tools/xenstore/xenstored_control.c
> >> +++ b/tools/xenstore/xenstored_control.c
> >> @@ -76,6 +76,41 @@ static int do_control_logfile(void *ctx, struct 
> >> connection *conn,
> >>return 0;
> >>  }
> >>  
> >> +static int do_control_memreport(void *ctx, struct connection *conn,
> >> +  char **vec, int num)
> >> +{
> >> +  FILE *fp;
> >> +  int fd;
> >> +
> >> +  if (num > 1)
> >> +  return EINVAL;
> >> +
> >> +  if (num == 0) {
> >> +  if (tracefd < 0) {
> >> +  if (!tracefile)
> >> +  return EBADF;
> >> +  fp = fopen(tracefile, "a");
> >> +  } else {
> >> +  fd = dup(tracefd);
> > 
> > Why dup() the fd? Is it because you want to avoid tracefd becomes
> > invalid under your feet?
> > 
> 
> I want to be able to fclose() to get rid of the stream resources without
> closing the log file.
> 

Oh, right. I missed that aspect. Could you please add a comment for that
please.

> 
> Juergen

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

Re: [Xen-devel] [PATCH v2 4/5] xenstore: make memory report available via XS_CONTROL

[Juergen Gross]

On 22/02/17 13:47, Wei Liu wrote:
> On Wed, Feb 22, 2017 at 01:43:27PM +0100, Juergen Gross wrote:
>> On 22/02/17 13:36, Wei Liu wrote:
>>> On Tue, Feb 21, 2017 at 04:07:36PM +0100, Juergen Gross wrote:
 Add a XS_CONTROL command to xenstored for doing a talloc report to a
 file. Right now this is supported by specifying a command line option
 when starting xenstored and sending a signal to the daemon to trigger
 the report.

 To dump the report to the standard log file call:

 xenstore-control memreport

 To dump the report to a new file call:

 xenstore-control memreport 

 Signed-off-by: Juergen Gross 
 ---
  tools/xenstore/xenstored_control.c | 36 
 
  tools/xenstore/xenstored_core.c|  2 +-
  tools/xenstore/xenstored_core.h|  1 +
  3 files changed, 38 insertions(+), 1 deletion(-)

 diff --git a/tools/xenstore/xenstored_control.c 
 b/tools/xenstore/xenstored_control.c
 index c3587ad..b4ec6ce 100644
 --- a/tools/xenstore/xenstored_control.c
 +++ b/tools/xenstore/xenstored_control.c
 @@ -76,6 +76,41 @@ static int do_control_logfile(void *ctx, struct 
 connection *conn,
return 0;
  }
  
 +static int do_control_memreport(void *ctx, struct connection *conn,
 +  char **vec, int num)
 +{
 +  FILE *fp;
 +  int fd;
 +
 +  if (num > 1)
 +  return EINVAL;
 +
 +  if (num == 0) {
 +  if (tracefd < 0) {
 +  if (!tracefile)
 +  return EBADF;
 +  fp = fopen(tracefile, "a");
 +  } else {
 +  fd = dup(tracefd);
>>>
>>> Why dup() the fd? Is it because you want to avoid tracefd becomes
>>> invalid under your feet?
>>>
>>
>> I want to be able to fclose() to get rid of the stream resources without
>> closing the log file.
>>
> 
> Oh, right. I missed that aspect. Could you please add a comment for that
> please.

Sure.


Juergen


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

[Xen-devel] What is via in HVM_CALLBACK_VECTOR part?

[Yuming Wu]

Hi,

I am learning event channel implementation in xen and evtchn driver in
linux.
When PVHVM guest boot, it will set callback vector using function void
*xen_callback_vector(void)*
which will call *xen_set_callback_via()*

The logic itself is simple but I don't know what the '*via*' stands for.
Would you please kindly tell me the full name of '*via*'?

Thanks

-- 
Yuming Wu
Institute of Parallel and Distributed Systems (IPADS),
Shanghai Jiao Tong University
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] VM Live Migration with Local Storage

[Wei Liu]

Hi Bruno

Thanks for your interest.

On Tue, Feb 21, 2017 at 10:34:45AM -0800, Bruno Alvisio wrote:
> Hello,
> 
> I have been to doing some research and as far as I know XEN supports
> Live Migration
> of VMs that only have shared storage. (i.e. iSCSI) If the VM has been
> booted with local storage it cannot be live migrated.
> QEMU seems to support live migration with local storage (I have tested using
> 'virsh migrate with the '--storage-copy-all' option)
> 
> I am wondering if this still true in the latest XEN release. Are there plans
> to add this functionality in future releases? I would be interested in
> contributing to the Xen Project by adding this functionality.
> 

No plan at the moment.

Xen supports a wide variety of disk backends. QEMU is one of them. The
others are blktap (not upstreamed yet) and in-kernel blkback. The latter
two don't have the capability to copy local storage to the remote end.

That said, I think it would be valuable to have such capability for QEMU
backed disks. We also need to design the machinery so that other
backends can be made to do the same thing in the future.

If you want to undertake this project, I suggest you setup a Xen system,
read xl / libxl source code under tools directory and understand how
everything is put together. Reading source code could be daunting at
times, so don't hesitate to ask for pointers. After you have the big
picture in mind, we can then discuss how to implement the functionality
on xen-devel.

Does this sound good to you?

Wei.

> Thanks,
> 
> Bruno

> ___
> 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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

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-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 build-arm64   5 xen-buildfail   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-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-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail 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-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-xsm  13 saverestore-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-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-credit2  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-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:
 qemuu796b288f7be875045670f963ce1b3c8e96ac
baseline version:
 qemuu56f9e46b841c7be478ca038d8d4085d776ab4b0d

Last test of basis   105943  2017-02-21 07:43:53 Z1 days
Testing same since   105962  2017-02-21 20:42:52 Z0 days1 attempts


People who touched revisions under test:
  Alistair Francis 
  Anton Nefedov 
  Artyom Tarasenko 
  Denis V. Lunev 
  Gerd Hoffmann 
  Jeff Cody 
  Kevin Wolf 
  Li Qiang 
  Markus Armbruster 
  Paolo Bonzini 
  Peter Maydell 
  Stefan Hajnoczi 
  Thomas Huth 

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  

Re: [Xen-devel] [PATCH] Include libxendevicemodel with libxc

[Wei Liu]

On Wed, Feb 22, 2017 at 12:04:18PM +0100, Samuel Thibault wrote:
> Paul Durrant, on mer. 22 févr. 2017 11:03:37 +, wrote:
> > libxendevicemodel has just been split out from libxc. From mini-os's
> > point of view we don't care about the distinction, so keep things
> > simple by just including libxendevicemodel if libxc is enabled.
> > 
> > Signed-off-by: Paul Durrant 
> > Cc: Samuel Thibault 
> 
> Acked-by: Samuel Thibault 

Applied.

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

Re: [Xen-devel] [PATCH 07/28] ARM: GICv3 ITS: introduce device mapping

[Julien Grall]

Hi Andre,

On 30/01/17 18:31, Andre Przywara wrote:

diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index 6578e8a..4a3a394 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c


[...]



+
+int gicv3_its_map_guest_device(struct domain *d, int host_devid,
+   int guest_devid, int bits, bool valid)


Whilst looking at the IORT table it occurred to me that the DeviceID may 
not be uniq accross all the ITSes on the platform.


This means 2 ITS could use the same DeviceID for different devices. 
However, this function assume the DeviceID will always be uniq.


So we would need to know specify the pITS and vITS for all PCI devices.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] What is via in HVM_CALLBACK_VECTOR part?

[Wei Liu]

On Wed, Feb 22, 2017 at 08:57:33PM +0800, Yuming Wu wrote:
> Hi,
> 
> I am learning event channel implementation in xen and evtchn driver in
> linux.
> When PVHVM guest boot, it will set callback vector using function void
> *xen_callback_vector(void)*
> which will call *xen_set_callback_via()*
> 
> The logic itself is simple but I don't know what the '*via*' stands for.
> Would you please kindly tell me the full name of '*via*'?
> 

As I understand it, "via" is not short-form of any word, it is just
"via" the word itself, as in "via this vector".

I'm happy to be proven wrong by the Linux maintainers. :-)

Wei.

> Thanks
> 
> -- 
> Yuming Wu
> Institute of Parallel and Distributed Systems (IPADS),
> Shanghai Jiao Tong University

> ___
> 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] [linux-linus test] 104684: regressions - FAIL

[Ian Jackson]

Julien Grall writes ("Re: [Xen-devel] [linux-linus test] 104684: regressions - 
FAIL"):
> On 14/02/17 17:42, Wei Liu wrote:
> > (test-lab)liuw@osstest:~/testing.git$ ./mg-hosts showprops | grep DTUART | 
> > grep arndale
> >  arndale-bluewater  XenDTUARTPath  /serial@12C2
> >  arndale-lakeside   XenDTUARTPath  /serial@12C2
> >  arndale-metrocentre XenDTUARTPath  /serial@12C2
> >  arndale-westfield  XenDTUARTPath  /serial@12C2
> >
> > That's a property of this kind of hosts in osstest. It needs to be
> > updated by the administrator (Ian).
> 
> Ian, could you change the XenDTUARTPath property for the arndale from 
> "/serial@12C2" to "serial0"?

Done.

> This should hopefully fix boot of Linux upstream on the board and keep 
> compatibility with the previous version of Linux.

Let's hope it doesn't break anything :-).

Ian.

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

Re: [Xen-devel] What is via in HVM_CALLBACK_VECTOR part?

[Jan Beulich]

>>> On 22.02.17 at 13:57,  wrote:
> I am learning event channel implementation in xen and evtchn driver in
> linux.
> When PVHVM guest boot, it will set callback vector using function void
> *xen_callback_vector(void)*
> which will call *xen_set_callback_via()*
> 
> The logic itself is simple but I don't know what the '*via*' stands for.
> Would you please kindly tell me the full name of '*via*'?

This is the English word "via", i.e. which approach (route) to take.

Jan


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

[Xen-devel] [PATCH v2 4/5] tools/libxendevicemodel: introduce a Linux-specific implementation

[Paul Durrant]

My recent patch [1] to the Linux privcmd module introduced a dedicated
mechanism for making dm_op hypercalls.

This patch adds the necessary code to libxendevicemodel to take
advantage of that mechanism if it is implemented in the tools domain
kernel.

[1] 
https://git.kernel.org/cgit/linux/kernel/git/ostr/linux.git/commit/?id=ab520be8

Signed-off-by: Paul Durrant 
Acked-by: Wei Liu 
---
Cc: Ian Jackson 
---
 tools/include/xen-sys/Linux/privcmd.h |  13 
 tools/libs/devicemodel/Makefile   |   2 +-
 tools/libs/devicemodel/linux.c| 123 ++
 tools/libs/devicemodel/private.h  |   4 ++
 4 files changed, 141 insertions(+), 1 deletion(-)
 create mode 100644 tools/libs/devicemodel/linux.c

diff --git a/tools/include/xen-sys/Linux/privcmd.h 
b/tools/include/xen-sys/Linux/privcmd.h
index e4e666a..c80eb5e 100644
--- a/tools/include/xen-sys/Linux/privcmd.h
+++ b/tools/include/xen-sys/Linux/privcmd.h
@@ -75,6 +75,17 @@ typedef struct privcmd_mmapbatch_v2 {
int __user *err;  /* array of error codes */
 } privcmd_mmapbatch_v2_t;
 
+typedef struct privcmd_dm_op_buf {
+   void __user *uptr;
+   size_t size;
+} privcmd_dm_op_buf_t;
+
+typedef struct privcmd_dm_op {
+   domid_t dom;
+   __u16 num;
+   const privcmd_dm_op_buf_t __user *ubufs;
+} privcmd_dm_op_t;
+
 /*
  * @cmd: IOCTL_PRIVCMD_HYPERCALL
  * @arg: &privcmd_hypercall_t
@@ -88,5 +99,7 @@ typedef struct privcmd_mmapbatch_v2 {
_IOC(_IOC_NONE, 'P', 3, sizeof(privcmd_mmapbatch_t))
 #define IOCTL_PRIVCMD_MMAPBATCH_V2 \
_IOC(_IOC_NONE, 'P', 4, sizeof(privcmd_mmapbatch_v2_t))
+#define IOCTL_PRIVCMD_DM_OP\
+   _IOC(_IOC_NONE, 'P', 5, sizeof(privcmd_dm_op_t))
 
 #endif /* __LINUX_PUBLIC_PRIVCMD_H__ */
diff --git a/tools/libs/devicemodel/Makefile b/tools/libs/devicemodel/Makefile
index b87bf84..1803942 100644
--- a/tools/libs/devicemodel/Makefile
+++ b/tools/libs/devicemodel/Makefile
@@ -11,7 +11,7 @@ CFLAGS   += $(CFLAGS_libxentoollog)
 CFLAGS   += $(CFLAGS_libxencall)
 
 SRCS-y += core.c
-SRCS-$(CONFIG_Linux)   += compat.c
+SRCS-$(CONFIG_Linux)   += linux.c
 SRCS-$(CONFIG_FreeBSD) += compat.c
 SRCS-$(CONFIG_SunOS)   += compat.c
 SRCS-$(CONFIG_NetBSD)  += compat.c
diff --git a/tools/libs/devicemodel/linux.c b/tools/libs/devicemodel/linux.c
new file mode 100644
index 000..7511ee7
--- /dev/null
+++ b/tools/libs/devicemodel/linux.c
@@ -0,0 +1,123 @@
+/*
+ * Copyright (c) 2017 Citrix Systems Inc.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include "private.h"
+
+int osdep_xendevicemodel_open(xendevicemodel_handle *dmod)
+{
+int fd = open("/dev/xen/privcmd", O_RDWR | O_CLOEXEC);
+privcmd_dm_op_t uop;
+int rc;
+
+if (fd < 0) {
+/*
+ * If the 'new' privcmd interface doesn't exist then don't treat
+ * this as an error, but an old privcmd clearly won't implement
+ * IOCTL_PRIVCMD_DM_OP so don't bother trying to open it.
+ */
+if (errno == ENOENT || errno == ENXIO || errno == ENODEV)
+goto out;
+
+PERROR("Could not obtain handle on privileged command interface");
+return -1;
+}
+
+/*
+ * Check to see if IOCTL_PRIVCMD_DM_OP is implemented as we want to
+ * use that in preference to libxencall.
+ */
+uop.dom = DOMID_INVALID;
+uop.num = 0;
+uop.ubufs = NULL;
+
+rc = ioctl(fd, IOCTL_PRIVCMD_DM_OP, &uop);
+if (rc < 0) {
+close(fd);
+fd = -1;
+}
+
+out:
+dmod->fd = fd;
+return 0;
+}
+
+int osdep_xendevicemodel_close(xendevicemodel_handle *dmod)
+{
+if (dmod->fd < 0)
+return 0;
+
+return close(dmod->fd);
+}
+
+int osdep_xendevicemodel_op(xendevicemodel_handle *dmod,
+domid_t domid, unsigned int nr_bufs,
+struct xendevicemodel_buf bufs[])
+{
+privcmd_dm_op_buf_t *ubufs;
+privcmd_dm_op_t uop;
+unsigned int i;
+int rc;
+
+if (dmod->fd < 0)
+return xendevicemodel_xcall(dmod, domid, nr_bufs, bufs);
+
+ubufs = calloc(nr_bufs, sizeof (*ubufs));
+if (!ubufs)
+return -1;
+
+for (i = 0; i < nr_bufs; i++) {
+ubufs[i].uptr =

[Xen-devel] [PATCH v2 2/5] tools/libxendevicemodel: introduce the new library

[Paul Durrant]

The new xendevicemodel library is intended to be used by all Xen device
models such that the only hypercall that use will be the dm_op hypercall
added by commit 524a98c2.

This patch adds the boilerplate for the new library, with only open() and
close() entry points, and calls to those from libxenctrl in preparation
for the compat layer added by a subsequent patch.

Signed-off-by: Paul Durrant 
Acked-by: Samuel Thibault 
---
Cc: Ian Jackson 
Cc: Wei Liu 

NOTE TO COMMITTERS:

The URLs and tags for qemu-xen-traditional and mini-is in the patch to
Config.mk need to be substituted with the correct URLs and tags after
the appropriate (recently posted) patches have been committed into the
master branches.

v2:
- Added patch to Config.mk
---
 Config.mk   | 12 ++---
 stubdom/Makefile| 17 ++-
 tools/Makefile  |  1 +
 tools/Rules.mk  | 10 +++-
 tools/libs/Makefile |  1 +
 tools/libs/devicemodel/Makefile | 66 
 tools/libs/devicemodel/core.c   | 68 +
 tools/libs/devicemodel/include/xendevicemodel.h | 40 +++
 tools/libs/devicemodel/libxendevicemodel.map|  6 +++
 tools/libs/devicemodel/private.h| 22 
 tools/libxc/Makefile|  3 +-
 tools/libxc/xc_private.c|  8 +++
 tools/libxc/xc_private.h|  4 ++
 13 files changed, 247 insertions(+), 11 deletions(-)
 create mode 100644 tools/libs/devicemodel/Makefile
 create mode 100644 tools/libs/devicemodel/core.c
 create mode 100644 tools/libs/devicemodel/include/xendevicemodel.h
 create mode 100644 tools/libs/devicemodel/libxendevicemodel.map
 create mode 100644 tools/libs/devicemodel/private.h

diff --git a/Config.mk b/Config.mk
index 9a28d15..d6d40cb 100644
--- a/Config.mk
+++ b/Config.mk
@@ -257,19 +257,19 @@ endif
 ifeq ($(GIT_HTTP),y)
 OVMF_UPSTREAM_URL ?= http://xenbits.xen.org/git-http/ovmf.git
 QEMU_UPSTREAM_URL ?= http://xenbits.xen.org/git-http/qemu-xen.git
-QEMU_TRADITIONAL_URL ?= 
http://xenbits.xen.org/git-http/qemu-xen-traditional.git
+QEMU_TRADITIONAL_URL ?= 
http://xenbits.xen.org/git-http/people/pauldu/qemu-xen-traditional.git
 SEABIOS_UPSTREAM_URL ?= http://xenbits.xen.org/git-http/seabios.git
-MINIOS_UPSTREAM_URL ?= http://xenbits.xen.org/git-http/mini-os.git
+MINIOS_UPSTREAM_URL ?= 
http://xenbits.xen.org/git-http/people/pauldu/mini-os.git
 else
 OVMF_UPSTREAM_URL ?= git://xenbits.xen.org/ovmf.git
 QEMU_UPSTREAM_URL ?= git://xenbits.xen.org/qemu-xen.git
-QEMU_TRADITIONAL_URL ?= git://xenbits.xen.org/qemu-xen-traditional.git
+QEMU_TRADITIONAL_URL ?= 
git://xenbits.xen.org/people/pauldu/qemu-xen-traditional.git
 SEABIOS_UPSTREAM_URL ?= git://xenbits.xen.org/seabios.git
-MINIOS_UPSTREAM_URL ?= git://xenbits.xen.org/mini-os.git
+MINIOS_UPSTREAM_URL ?= git://xenbits.xen.org/people/pauldu/mini-os.git
 endif
 OVMF_UPSTREAM_REVISION ?= 5734d486b6aa0b69a39b2c8d52b355400bcf2551
 QEMU_UPSTREAM_REVISION ?= master
-MINIOS_UPSTREAM_REVISION ?= 1e8e464febb32428c7651b0b585866e5ee5f786e
+MINIOS_UPSTREAM_REVISION ?= master
 # Tue Dec 13 15:02:02 2016 +
 # build: prepend OBJ_DIR to linker script
 
@@ -280,7 +280,7 @@ SEABIOS_UPSTREAM_REVISION ?= rel-1.10.0
 ETHERBOOT_NICS ?= rtl8139 8086100e
 
 
-QEMU_TRADITIONAL_REVISION ?= b669e922b37b8957248798a5eb7aa96a666cd3fe
+QEMU_TRADITIONAL_REVISION ?= master
 # Mon Nov 14 17:19:46 2016 +
 # qemu: ioport_read, ioport_write: be defensive about 32-bit addresses
 
diff --git a/stubdom/Makefile b/stubdom/Makefile
index f858210..39b81c9 100644
--- a/stubdom/Makefile
+++ b/stubdom/Makefile
@@ -337,13 +337,16 @@ libs-$(XEN_TARGET_ARCH)/call/stamp: 
$(XEN_ROOT)/tools/libs/call/Makefile
 libs-$(XEN_TARGET_ARCH)/foreignmemory/stamp: 
$(XEN_ROOT)/tools/libs/foreignmemory/Makefile
$(do_links)
 
+libs-$(XEN_TARGET_ARCH)/devicemodel/stamp: 
$(XEN_ROOT)/tools/libs/devicemodel/Makefile
+   $(do_links)
+
 libxc-$(XEN_TARGET_ARCH)/stamp: $(XEN_ROOT)/tools/libxc/Makefile
$(do_links)
 
 xenstore/stamp: $(XEN_ROOT)/tools/xenstore/Makefile
$(do_links)
 
-LINK_LIBS_DIRS := toollog evtchn gnttab call foreignmemory
+LINK_LIBS_DIRS := toollog evtchn gnttab call foreignmemory devicemodel
 LINK_DIRS := libxc-$(XEN_TARGET_ARCH) xenstore $(foreach 
dir,$(LINK_LIBS_DIRS),libs-$(XEN_TARGET_ARCH)/$(dir))
 LINK_STAMPS := $(foreach dir,$(LINK_DIRS),$(dir)/stamp)
 
@@ -414,12 +417,21 @@ 
libs-$(XEN_TARGET_ARCH)/foreignmemory/libxenforeignmemory.a: mk-headers-$(XEN_TA
CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" $(MAKE) 
DESTDIR= -C libs-$(XEN_TARGET_ARCH)/foreignmemory
 
 ###
+# libxendevicemodel
+###
+
+.PHONY: libxendevicemodel
+libxendevicemodel: libs-$(XEN_TARGET_ARCH)/devicemodel/libxendevicemodel.a
+libs-$(XEN_TARGET_ARCH)/devicemodel/libxendevicemodel.a:

[Xen-devel] [PATCH v2 0/5] tools/libxendevicemodel

[Paul Durrant]

Paul Durrant (5):
  tools/libxenctrl: fix error check after opening libxenforeignmemory
  tools/libxendevicemodel: introduce the new library
  tools/libxendevicemodel: extract functions and add a compat layer
  tools/libxendevicemodel: introduce a Linux-specific implementation
  tools/libxendevicemodel: add a call to restrict the handle

 Config.mk   |  12 +-
 stubdom/Makefile|  17 +-
 tools/Makefile  |   2 +
 tools/Rules.mk  |  10 +-
 tools/include/xen-sys/Linux/privcmd.h   |  15 +
 tools/libs/Makefile |   1 +
 tools/libs/devicemodel/Makefile |  72 
 tools/libs/devicemodel/compat.c |  54 +++
 tools/libs/devicemodel/core.c   | 508 
 tools/libs/devicemodel/include/xendevicemodel.h | 308 ++
 tools/libs/devicemodel/libxendevicemodel.map|  23 ++
 tools/libs/devicemodel/linux.c  | 134 +++
 tools/libs/devicemodel/private.h|  48 +++
 tools/libxc/Makefile|   4 +-
 tools/libxc/include/xenctrl.h   | 197 -
 tools/libxc/include/xenctrl_compat.h|  47 +++
 tools/libxc/xc_devicemodel_compat.c | 139 +++
 tools/libxc/xc_domain.c | 201 --
 tools/libxc/xc_misc.c   | 154 ---
 tools/libxc/xc_private.c|  82 +---
 tools/libxc/xc_private.h|   4 +
 21 files changed, 1395 insertions(+), 637 deletions(-)
 create mode 100644 tools/libs/devicemodel/Makefile
 create mode 100644 tools/libs/devicemodel/compat.c
 create mode 100644 tools/libs/devicemodel/core.c
 create mode 100644 tools/libs/devicemodel/include/xendevicemodel.h
 create mode 100644 tools/libs/devicemodel/libxendevicemodel.map
 create mode 100644 tools/libs/devicemodel/linux.c
 create mode 100644 tools/libs/devicemodel/private.h
 create mode 100644 tools/libxc/xc_devicemodel_compat.c

-- 
2.1.4


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

[Xen-devel] [PATCH v2 5/5] tools/libxendevicemodel: add a call to restrict the handle

[Paul Durrant]

My recent patch [1] to the Linux privcmd module introduced a mechanism
to restrict an open file handle to subsequently only accept operations for
a specified domain.

This patch extends the libxendevicemodel API and make use of the
mechanism in the Linux-specific code to restrict operations on the
interface handle.

[1] 
https://git.kernel.org/cgit/linux/kernel/git/ostr/linux.git/commit/?id=4610d240

Signed-off-by: Paul Durrant 
Acked-by: Wei Liu 
---
Cc: Ian Jackson 
---
 tools/include/xen-sys/Linux/privcmd.h   |  2 ++
 tools/libs/devicemodel/compat.c |  9 +
 tools/libs/devicemodel/core.c   |  5 +
 tools/libs/devicemodel/include/xendevicemodel.h | 10 ++
 tools/libs/devicemodel/libxendevicemodel.map|  1 +
 tools/libs/devicemodel/linux.c  | 11 +++
 tools/libs/devicemodel/private.h|  3 +++
 7 files changed, 41 insertions(+)

diff --git a/tools/include/xen-sys/Linux/privcmd.h 
b/tools/include/xen-sys/Linux/privcmd.h
index c80eb5e..732ff7c 100644
--- a/tools/include/xen-sys/Linux/privcmd.h
+++ b/tools/include/xen-sys/Linux/privcmd.h
@@ -101,5 +101,7 @@ typedef struct privcmd_dm_op {
_IOC(_IOC_NONE, 'P', 4, sizeof(privcmd_mmapbatch_v2_t))
 #define IOCTL_PRIVCMD_DM_OP\
_IOC(_IOC_NONE, 'P', 5, sizeof(privcmd_dm_op_t))
+#define IOCTL_PRIVCMD_RESTRICT \
+   _IOC(_IOC_NONE, 'P', 6, sizeof(domid_t))
 
 #endif /* __LINUX_PUBLIC_PRIVCMD_H__ */
diff --git a/tools/libs/devicemodel/compat.c b/tools/libs/devicemodel/compat.c
index 245e907..5b4fdae 100644
--- a/tools/libs/devicemodel/compat.c
+++ b/tools/libs/devicemodel/compat.c
@@ -15,6 +15,8 @@
  * License along with this library; If not, see .
  */
 
+#include 
+
 #include "private.h"
 
 int osdep_xendevicemodel_open(xendevicemodel_handle *dmod)
@@ -34,6 +36,13 @@ int osdep_xendevicemodel_op(xendevicemodel_handle *dmod,
 return xendevicemodel_xcall(dmod, domid, nr_bufs, bufs);
 }
 
+int osdep_xendevicemodel_restrict(xendevicemodel_handle *dmod,
+  domid_t domid)
+{
+errno = EOPNOTSUPP;
+return -1;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libs/devicemodel/core.c b/tools/libs/devicemodel/core.c
index 33ee157..504543c 100644
--- a/tools/libs/devicemodel/core.c
+++ b/tools/libs/devicemodel/core.c
@@ -492,6 +492,11 @@ int xendevicemodel_inject_event(
 return xendevicemodel_op(dmod, domid, 1, &op, sizeof(op));
 }
 
+int xendevicemodel_restrict(xendevicemodel_handle *dmod, domid_t domid)
+{
+return osdep_xendevicemodel_restrict(dmod, domid);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libs/devicemodel/include/xendevicemodel.h 
b/tools/libs/devicemodel/include/xendevicemodel.h
index e00f8da..b3f600e 100644
--- a/tools/libs/devicemodel/include/xendevicemodel.h
+++ b/tools/libs/devicemodel/include/xendevicemodel.h
@@ -283,6 +283,16 @@ int xendevicemodel_inject_event(
 xendevicemodel_handle *dmod, domid_t domid, int vcpu, uint8_t vector,
 uint8_t type, uint32_t error_code, uint8_t insn_len, uint64_t cr2);
 
+/**
+ * This function restricts the use of this handle to the specified
+ * domain.
+ *
+ * @parm dmod handle to the open devicemodel interface
+ * @parm domid the domain id
+ * @return 0 on success, -1 on failure.
+ */
+int xendevicemodel_restrict(xendevicemodel_handle *dmod, domid_t domid);
+
 #endif /* __XEN_TOOLS__ */
 
 #endif /* XENDEVICEMODEL_H */
diff --git a/tools/libs/devicemodel/libxendevicemodel.map 
b/tools/libs/devicemodel/libxendevicemodel.map
index abc6d06..45c773e 100644
--- a/tools/libs/devicemodel/libxendevicemodel.map
+++ b/tools/libs/devicemodel/libxendevicemodel.map
@@ -17,6 +17,7 @@ VERS_1.0 {
xendevicemodel_modified_memory;
xendevicemodel_set_mem_type;
xendevicemodel_inject_event;
+   xendevicemodel_restrict;
xendevicemodel_close;
local: *; /* Do not expose anything by default */
 };
diff --git a/tools/libs/devicemodel/linux.c b/tools/libs/devicemodel/linux.c
index 7511ee7..438c55b 100644
--- a/tools/libs/devicemodel/linux.c
+++ b/tools/libs/devicemodel/linux.c
@@ -112,6 +112,17 @@ int osdep_xendevicemodel_op(xendevicemodel_handle *dmod,
 return 0;
 }
 
+int osdep_xendevicemodel_restrict(xendevicemodel_handle *dmod,
+  domid_t domid)
+{
+if (dmod->fd < 0) {
+errno = EOPNOTSUPP;
+return -1;
+}
+
+return ioctl(dmod->fd, IOCTL_PRIVCMD_RESTRICT, &domid);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libs/devicemodel/private.h b/tools/libs/devicemodel/private.h
index 5ce3b45..4ce5aac 100644
--- a/tools/libs/devicemodel/private.h
+++ b/tools/libs/devicemodel/private.h
@@ -29,6 +29,9 @@ int osdep_xendevicemodel_op(xendevicemodel_handle *dmod,
 domid_t domid, u

[Xen-devel] [PATCH v2 1/5] tools/libxenctrl: fix error check after opening libxenforeignmemory

[Paul Durrant]

Checking the value of xch->xcall is clearly incorrect. The code should be
checking xch->fmem (i.e. the return of the previously called function).

Signed-off-by: Paul Durrant 
---
Cc: Ian Jackson 
Cc: Wei Liu 
---
 tools/libxc/xc_private.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/tools/libxc/xc_private.c b/tools/libxc/xc_private.c
index f0e089c..9df6925 100644
--- a/tools/libxc/xc_private.c
+++ b/tools/libxc/xc_private.c
@@ -64,8 +64,7 @@ struct xc_interface_core *xc_interface_open(xentoollog_logger 
*logger,
 goto err;
 
 xch->fmem = xenforeignmemory_open(xch->error_handler, 0);
-
-if ( xch->xcall == NULL )
+if ( xch->fmem == NULL )
 goto err;
 
 return xch;
-- 
2.1.4


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

[Xen-devel] [PATCH v2 3/5] tools/libxendevicemodel: extract functions and add a compat layer

[Paul Durrant]

This patch extracts all functions resulting in a dm_op hypercall from
libxenctrl and moves them into libxendevicemodel. It also adds a compat
layer into libxenctrl, which can be selected by defining
XC_WANT_COMPAT_DEVICEMODEL_API to 1 before including xenctrl.h.

With this patch the core of libxendevicemodel still uses libxencall to
issue the dm_op hypercalls, but this is done by calling through code that
can be modified on a per-OS basis. A subsequent patch will add a Linux-
specific variant.

Signed-off-by: Paul Durrant 
---
Cc: Ian Jackson 
Cc: Wei Liu 

v2:
- Re-based on 78da0c2a "libxc: don't pass uninitialized data to
  do_dm_op()" and corrected implementation of
  xendevicemodel_track_dirty_vram() accordingly.
---
 tools/Makefile  |   1 +
 tools/Rules.mk  |   2 +-
 tools/libs/devicemodel/Makefile |  10 +-
 tools/libs/devicemodel/compat.c |  45 +++
 tools/libs/devicemodel/core.c   | 435 
 tools/libs/devicemodel/include/xendevicemodel.h | 258 ++
 tools/libs/devicemodel/libxendevicemodel.map|  16 +
 tools/libs/devicemodel/private.h|  19 ++
 tools/libxc/Makefile|   1 +
 tools/libxc/include/xenctrl.h   | 197 ---
 tools/libxc/include/xenctrl_compat.h|  47 +++
 tools/libxc/xc_devicemodel_compat.c | 139 
 tools/libxc/xc_domain.c | 201 ---
 tools/libxc/xc_misc.c   | 154 -
 tools/libxc/xc_private.c|  73 
 15 files changed, 970 insertions(+), 628 deletions(-)
 create mode 100644 tools/libs/devicemodel/compat.c
 create mode 100644 tools/libxc/xc_devicemodel_compat.c

diff --git a/tools/Makefile b/tools/Makefile
index 0890cc9..e6c0cc5 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -262,6 +262,7 @@ subdir-all-qemu-xen-dir: qemu-xen-dir-find
--extra-cflags="-DXC_WANT_COMPAT_EVTCHN_API=1 \
-DXC_WANT_COMPAT_GNTTAB_API=1 \
-DXC_WANT_COMPAT_MAP_FOREIGN_API=1 \
+   -DXC_WANT_COMPAT_DEVICEMODEL_API=1 \
-I$(XEN_ROOT)/tools/include \
-I$(XEN_ROOT)/tools/libs/toollog/include \
-I$(XEN_ROOT)/tools/libs/evtchn/include \
diff --git a/tools/Rules.mk b/tools/Rules.mk
index e3415f0..8ea3901 100644
--- a/tools/Rules.mk
+++ b/tools/Rules.mk
@@ -119,7 +119,7 @@ LDLIBS_libxenforeignmemory = 
$(XEN_LIBXENFOREIGNMEMORY)/libxenforeignmemory$(lib
 SHLIB_libxenforeignmemory  = -Wl,-rpath-link=$(XEN_LIBXENFOREIGNMEMORY)
 
 CFLAGS_libxendevicemodel = -I$(XEN_LIBXENDEVICEMODEL)/include 
$(CFLAGS_xeninclude)
-SHDEPS_libxendevicemodel = $(SHLIB_libxentoollog)
+SHDEPS_libxendevicemodel = $(SHLIB_libxentoollog) $(SHLIB_xencall)
 LDLIBS_libxendevicemodel = 
$(XEN_LIBXENDEVICEMODEL)/libxendevicemodel$(libextension)
 SHLIB_libxendevicemodel  = -Wl,-rpath-link=$(XEN_LIBXENDEVICEMODEL)
 
diff --git a/tools/libs/devicemodel/Makefile b/tools/libs/devicemodel/Makefile
index 4f1e616..b87bf84 100644
--- a/tools/libs/devicemodel/Makefile
+++ b/tools/libs/devicemodel/Makefile
@@ -8,8 +8,14 @@ SHLIB_LDFLAGS += -Wl,--version-script=libxendevicemodel.map
 CFLAGS   += -Werror -Wmissing-prototypes
 CFLAGS   += -I./include $(CFLAGS_xeninclude)
 CFLAGS   += $(CFLAGS_libxentoollog)
-
-SRCS-y   += core.c
+CFLAGS   += $(CFLAGS_libxencall)
+
+SRCS-y += core.c
+SRCS-$(CONFIG_Linux)   += compat.c
+SRCS-$(CONFIG_FreeBSD) += compat.c
+SRCS-$(CONFIG_SunOS)   += compat.c
+SRCS-$(CONFIG_NetBSD)  += compat.c
+SRCS-$(CONFIG_MiniOS)  += compat.c
 
 LIB_OBJS := $(patsubst %.c,%.o,$(SRCS-y))
 PIC_OBJS := $(patsubst %.c,%.opic,$(SRCS-y))
diff --git a/tools/libs/devicemodel/compat.c b/tools/libs/devicemodel/compat.c
new file mode 100644
index 000..245e907
--- /dev/null
+++ b/tools/libs/devicemodel/compat.c
@@ -0,0 +1,45 @@
+/*
+ * Copyright (c) 2017 Citrix Systems Inc.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; If not, see .
+ */
+
+#include "private.h"
+
+int osdep_xendevicemodel_open(xendevicemodel_handle *dmod)
+{
+return 0;
+}
+
+int osdep_xendevicemodel_close(xendevicemodel_handle *dmod)
+{
+return 0;
+}
+
+int osdep_xendevicemodel_op(xendevicemodel_handle *dmod,
+domid_t domid, unsigned int nr_bufs,
+ 

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

[Jan Beulich]

>>> On 21.02.17 at 20:24,  wrote:
> On Tue, Feb 21, 2017 at 08:19:53PM +0100, Daniel Kiper wrote:
>> This way Xen can be loaded on EFI platforms using GRUB2 and
>> other boot loaders which support multiboot2 protocol.
>>
>> Signed-off-by: Daniel Kiper 
>> ---
>> v16 - suggestions/fixes:
>> - improve comments in error handling
>>   (suggested by Jan Beulich).
> 
> Diff between v15 and v16:

While I'm still not really happy with the changes done, and the VGA
(or not) handling in general, after discussing this yet another time
with Andrew we've decided to put in at least the first 4 patches. The
rest of the series will need to have the reported regression (by
Doug) taken care of to become a candidate for committing.

Jan


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

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

[osstest service owner]

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

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-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  24682c89d05c99711f02ec280f82ea24cef2
baseline version:
 xen  b908131167a67a16fbe9c7a7826b67e2d93d9ec5

Last test of basis   105953  2017-02-21 15:02:01 Z0 days
Testing same since   105985  2017-02-22 12:01:21 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 
  Kevin Tian 

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=24682c89d05c99711f02ec280f82ea24cef2
+ . ./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 
24682c89d05c99711f02ec280f82ea24cef2
+ branch=xen-unstable-smoke
+ revision=24682c89d05c99711f02ec280f82ea24cef2
+ . ./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
+ '[' x24682c89d05c99711f02ec280f82ea24cef2 = 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.g

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

[Doug Goldstein]

On 2/22/17 5:42 AM, Jan Beulich wrote:
 On 21.02.17 at 20:24,  wrote:
>> On Tue, Feb 21, 2017 at 08:19:53PM +0100, Daniel Kiper wrote:
>>> This way Xen can be loaded on EFI platforms using GRUB2 and
>>> other boot loaders which support multiboot2 protocol.
>>>
>>> Signed-off-by: Daniel Kiper 
>>> ---
>>> v16 - suggestions/fixes:
>>> - improve comments in error handling
>>>   (suggested by Jan Beulich).
>>
>> Diff between v15 and v16:
> 
> While I'm still not really happy with the changes done, and the VGA
> (or not) handling in general, after discussing this yet another time
> with Andrew we've decided to put in at least the first 4 patches. The
> rest of the series will need to have the reported regression (by
> Doug) taken care of to become a candidate for committing.
> 
> Jan
> 

I'm on travel for the next week and half but when I return I had planned
on tackling the issue.

For anyone else interested its reproducible with QEMU booting smp with 2
CPUs and using OVMF. Xen just never sees more than the boot CPU. I'd
recommend using QEMU master since they landed some fixes so that the
debugger can handle switching from 64-bit to 32-bit and back again.

-- 
Doug Goldstein



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 12/19] x86/mce: handle LMCE locally

[Jan Beulich]

>>> On 17.02.17 at 07:39,  wrote:
> --- a/xen/arch/x86/cpu/mcheck/barrier.c
> +++ b/xen/arch/x86/cpu/mcheck/barrier.c
> @@ -20,7 +20,7 @@ void mce_barrier_enter(struct mce_softirq_barrier *bar)
>  {
>  int gen;
>  
> -if (!mce_broadcast)
> +if ( !mce_broadcast || __get_cpu_var(lmce_in_process) )

this_cpu() please instead of __get_cpu_var() (which we should get
rid of rather sooner than later).

> @@ -462,6 +474,7 @@ void mcheck_cmn_handler(const struct cpu_user_regs *regs)
>  uint64_t gstatus;
>  mctelem_cookie_t mctc = NULL;
>  struct mca_summary bs;
> +bool *lmce_in_process = &__get_cpu_var(lmce_in_process);
>  
>  mce_spin_lock(&mce_logout_lock);
>  
> @@ -505,6 +518,8 @@ void mcheck_cmn_handler(const struct cpu_user_regs *regs)
>  }
>  mce_spin_unlock(&mce_logout_lock);
>  
> +*lmce_in_process = bs.lmce;

You don't need a new local variable for this.

> @@ -1709,6 +1724,7 @@ static void mce_softirq(void)
>  {
>  int cpu = smp_processor_id();
>  unsigned int workcpu;
> +bool lmce = per_cpu(lmce_in_process, cpu);

Is this flag valid to be looked at anymore at this point in time? MCIP
was cleared a lot earlier, so there may well have been a 2nd #MC
in between. In any event you again don#t need the local variable
here afaict.

Jan


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

Re: [Xen-devel] [PATCH v2 3/3] x86/vmx: fix vmentry failure with TSX bits in LBR

[Sergey Dyasli]

On Wed, 2017-02-22 at 03:26 -0700, Jan Beulich wrote:
> > > > On 17.02.17 at 16:42,  wrote:
> > 
> > --- a/xen/arch/x86/hvm/vmx/vmx.c
> > +++ b/xen/arch/x86/hvm/vmx/vmx.c
> > @@ -2284,6 +2284,8 @@ static void pi_notification_interrupt(struct 
> > cpu_user_regs *regs)
> >  raise_softirq(VCPU_KICK_SOFTIRQ);
> >  }
> >  
> > +static void __init vmx_lbr_tsx_fixup_check(void);
> 
> vmx_ prefixes are pretty pointless for static functions in this
> particular source file (there's at least one more below).

I agree on that. Will remove in v3.

> 
> > @@ -2876,7 +2938,11 @@ static int vmx_msr_write_intercept(unsigned int msr, 
> > uint64_t msr_content)
> >  for ( ; (rc == 0) && lbr->count; lbr++ )
> >  for ( i = 0; (rc == 0) && (i < lbr->count); i++ )
> >  if ( (rc = vmx_add_guest_msr(lbr->base + i)) == 0 )
> > +{
> >  vmx_disable_intercept_for_msr(v, lbr->base + i, 
> > MSR_TYPE_R | MSR_TYPE_W);
> > +if ( vmx_lbr_tsx_fixup_needed )
> > +v->arch.hvm_vmx.lbr_tsx_fixup_enabled = true;
> 
> Is there anything wrong with
> 
> v->arch.hvm_vmx.lbr_tsx_fixup_enabled = vmx_lbr_tsx_fixup_needed;
> 
> ?

Only 80 characters limit prevented me from doing it that way.

> 
> > --- a/xen/include/asm-x86/hvm/vmx/vmcs.h
> > +++ b/xen/include/asm-x86/hvm/vmx/vmcs.h
> > @@ -147,6 +147,7 @@ struct arch_vmx_struct {
> >  uint8_t  vmx_realmode;
> >  /* Are we emulating rather than VMENTERing? */
> >  uint8_t  vmx_emulate;
> > +bool lbr_tsx_fixup_enabled;
> >  /* Bitmask of segments that we can't safely use in virtual 8086 mode */
> >  uint16_t vm86_segment_mask;
> >  /* Shadow CS, SS, DS, ES, FS, GS, TR while in virtual 8086 mode */
> 
> Please put blank lines around your addition.

Will do in v3.

> 
> > --- a/xen/include/asm-x86/msr-index.h
> > +++ b/xen/include/asm-x86/msr-index.h
> > @@ -55,6 +55,8 @@
> >  #define MSR_IA32_PEBS_ENABLE   0x03f1
> >  #define MSR_IA32_DS_AREA   0x0600
> >  #define MSR_IA32_PERF_CAPABILITIES 0x0345
> > +/* Lower 6 bits define the format of the address in the LBR stack */
> > +#define LBR_FORMAT_MSR_IA32_PERF_CAP   0x3f
> 
> Commonly the MSR name precedes the field specific name component.

I was trying to follow the naming style in that file but I might've
gotten it wrong. The new define can be renamed to a more appropriate
name, I'm open to suggestions.

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

Re: [Xen-devel] [PATCH v2 3/3] x86/vmx: fix vmentry failure with TSX bits in LBR

[Andrew Cooper]

On 22/02/17 13:58, Sergey Dyasli wrote:
>
>>> @@ -2876,7 +2938,11 @@ static int vmx_msr_write_intercept(unsigned int msr, 
>>> uint64_t msr_content)
>>>  for ( ; (rc == 0) && lbr->count; lbr++ )
>>>  for ( i = 0; (rc == 0) && (i < lbr->count); i++ )
>>>  if ( (rc = vmx_add_guest_msr(lbr->base + i)) == 0 )
>>> +{
>>>  vmx_disable_intercept_for_msr(v, lbr->base + i, 
>>> MSR_TYPE_R | MSR_TYPE_W);
>>> +if ( vmx_lbr_tsx_fixup_needed )
>>> +v->arch.hvm_vmx.lbr_tsx_fixup_enabled = true;
>> Is there anything wrong with
>>
>> v->arch.hvm_vmx.lbr_tsx_fixup_enabled = vmx_lbr_tsx_fixup_needed;
>>
>> ?
> Only 80 characters limit prevented me from doing it that way.

Splitting after the = is acceptable, e.g.

v->arch.hvm_vmx.lbr_tsx_fixup_enabled =
vmx_lbr_tsx_fixup_needed;

~Andrew

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

Re: [Xen-devel] [PATCH v2 1/3] x86/vpmu: Add get/put_vpmu() and VPMU_AVAILABLE

[Boris Ostrovsky]

 +
 +void vpmu_initialise(struct vcpu *v)
 +{
 +get_vpmu(v);
 +
 +/*
 + * Guests without LAPIC (i.e. PV) call vpmu_arch_initialise()
 + * from pvpmu_init().
 + */
>>> implication is that PV VPMU is not counted then?
>> No. get_vpmu() is what does the counting now. Since we do
>> vcpu_initialise() -> vpmu_initialise() for all type of VCPUs both PV and
>> HVM VPMUs are counted here. But we defer arch-specific intialization
>> (which doesn't do the counting) for PV until the hypercall.
>>
> earlier comment said vpmu_count is to count active VPMUs.
> what's the definition of 'active' here?  An uninitialized pv VPMU
> is also considered active?

Yes. Whenever a VCPU with appropriately defined CPUID leaf  0xa is
initialized we should assume that it eventually will be used. I can
clarify the comment.

(In the second patch I claim that "appropriately defined" is version=0
but perhaps there is a better definition.)

-boris


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

[Xen-devel] xen/arm: Hiding SMMUs from Dom0 when using ACPI on Xen

[Julien Grall]

Hello,

There was few discussions recently about hiding SMMUs from DOM0 when 
using ACPI. I thought it would be good to have a separate thread for this.


When using ACPI, the SMMUs will be described in the IO Remapping Table 
(IORT). The specification can be found on the ARM website [1].


For a brief summary, the IORT can be used to discover the SMMUs present 
on the platform and find for a given device the ID to configure 
components such as ITS (DeviceID) and SMMU (StreamID).


The appendix A in the specification gives an example how DeviceID and 
StreamID can be found. For instance, when a PCI device is both protected 
by an SMMU and MSI-capable the following translation will happen:

RID -> StreamID -> DeviceID

Currently, SMMUs are hidden from DOM0 because they are been used by Xen 
and we don't support stage-1 SMMU. If we pass the IORT as it is, DOM0 
will try to initialize SMMU and crash.


I first thought about using a Xen specific way (STAO) or extending a 
flag in IORT. But that is not ideal.


So we would have to rewrite the IORT for DOM0. Given that a range of RID 
can mapped to multiple ranges of DeviceID, we would have to translate 
RID one by one to find the associated DeviceID. I think this may end up 
to complex code and have a big IORT table.


However, given that DeviceID will be used by DOM0 to only configure the 
ITS. We have no need to use to have the DOM0 DeviceID equal to the host 
DeviceID. So I think we could simplify our life by generating DeviceID 
for each RID range.


Any opinions?

Cheers,

[1] 
http://infocenter.arm.com/help/topic/com.arm.doc.den0049b/DEN0049B_IO_Remapping_Table.pdf


--
Julien Grall

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

Re: [Xen-devel] [PATCH v2 1/5] tools/libxenctrl: fix error check after opening libxenforeignmemory

[Wei Liu]

On Wed, Feb 22, 2017 at 01:27:34PM +, Paul Durrant wrote:
> Checking the value of xch->xcall is clearly incorrect. The code should be
> checking xch->fmem (i.e. the return of the previously called function).
> 
> Signed-off-by: Paul Durrant 

Acked-by: Wei Liu 

Ian, please backport this.

> ---
> Cc: Ian Jackson 
> Cc: Wei Liu 
> ---
>  tools/libxc/xc_private.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/tools/libxc/xc_private.c b/tools/libxc/xc_private.c
> index f0e089c..9df6925 100644
> --- a/tools/libxc/xc_private.c
> +++ b/tools/libxc/xc_private.c
> @@ -64,8 +64,7 @@ struct xc_interface_core 
> *xc_interface_open(xentoollog_logger *logger,
>  goto err;
>  
>  xch->fmem = xenforeignmemory_open(xch->error_handler, 0);
> -
> -if ( xch->xcall == NULL )
> +if ( xch->fmem == NULL )
>  goto err;
>  
>  return xch;
> -- 
> 2.1.4
> 

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

Re: [Xen-devel] [PATCH v2 1/5] tools/libxenctrl: fix error check after opening libxenforeignmemory

[Ian Jackson]

Paul Durrant writes ("[PATCH v2 1/5] tools/libxenctrl: fix error check after 
opening libxenforeignmemory"):
> Checking the value of xch->xcall is clearly incorrect. The code should be
> checking xch->fmem (i.e. the return of the previously called function).

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [linux-linus test] 104684: regressions - FAIL

[Julien Grall]

Hi Ian,

On 22/02/17 13:19, Ian Jackson wrote:

Julien Grall writes ("Re: [Xen-devel] [linux-linus test] 104684: regressions - 
FAIL"):

On 14/02/17 17:42, Wei Liu wrote:

(test-lab)liuw@osstest:~/testing.git$ ./mg-hosts showprops | grep DTUART | grep 
arndale
 arndale-bluewater  XenDTUARTPath  /serial@12C2
 arndale-lakeside   XenDTUARTPath  /serial@12C2
 arndale-metrocentre XenDTUARTPath  /serial@12C2
 arndale-westfield  XenDTUARTPath  /serial@12C2

That's a property of this kind of hosts in osstest. It needs to be
updated by the administrator (Ian).


Ian, could you change the XenDTUARTPath property for the arndale from
"/serial@12C2" to "serial0"?


Done.


This should hopefully fix boot of Linux upstream on the board and keep
compatibility with the previous version of Linux.


Let's hope it doesn't break anything :-).


Thank you! I will watch next flights on osstest.

Cheers,

--
Julien Grall

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