date:20160829

Yes, this will allow the hypervisor to collect samples from multiple
guests. However, the tool (perf) probably won't be able to properly
process these samples. But you can try.

I understand, thus, I applied the patches and set the pmu_mode to all. However,
I’m really curious what you mean by the tool (perf) probably won’t be able to
properly process these samples. Is there any things I have to have in mind
while collecting the counters, or will it have incorrect values of the counters?

You will want to run dom0 on all physical processors (i.e. no
dom0_max_vcpus boot option) and pin all VCPUs for both dom0 and the guest.

Sure, thanks! My machine has four physical cores, and I’ve set the
dom0_max_vcpus=4. I think it will have the same effect in removing the
dom0_max_vcpus option.

Best,
Sanghyun.

On Aug 29, 2016, at 4:59 PM, Boris Ostrovsky
> wrote:

On 08/29/2016 02:42 PM, Sanghyun Hong wrote:
Hi Boris,

I’ve found the
documentations(https://github.com/torvalds/linux/blob/master/Documentation/ABI/testing/sysfs-hypervisor-pmu)
in the kernel source code, and it seems like if we change the mode
from *self* to *all* then we can collect counters for all the domains,
right?

Yes, this will allow the hypervisor to collect samples from multiple
guests. However, the tool (perf) probably won't be able to properly
process these samples. But you can try.

You will want to run dom0 on all physical processors (i.e. no
dom0_max_vcpus boot option) and pin all VCPUs for both dom0 and the guest.

-boris

All the best,
Sanghyun.

On Aug 29, 2016, at 12:36 PM, Boris Ostrovsky

> wrote:

On 08/29/2016 09:18 AM, Sanghyun Hong wrote:
Dear Xen-Devel Community:

I’m a grad student working on measuring performance counters at the
Xen domains. I read this
thread(https://wiki.xenproject.org/wiki/Xen_Profiling:_oprofile_and_perf)
in
web, and it says using Linux perf command will let us collecting
performance counters in both dom0 and domU. Does it mean that we can
collect both of them at once if we run perf command on the dom0? (If
not, does it mean we can collect counters for each domain separately
once we run the perf command in each domain?

Profiling both guest and dom0 (and the hypervisor) requires changes to
perf and those are not there yet.

But you can run perf in each guest (including dom0) separately. Make
sure you have vpmu=true boot option.

-boris

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

Re: [Xen-devel] Questions about Using Perf at Dom0

Hi Boris,

[Appreciate for your support, and I have one last question]

Since we’re using the Xen hypervisor (not the KVM that is type-II), I think we 
cannot use the perf kvm command. Here are the outputs:

# perf kvm --host --guest record -C 1 sleep 1
[ perf record: Woken up 1 times to write data ]
Warning:
1 unprocessable samples recorded.
Do you have a KVM guest running and not using 'perf kvm'?
[ perf record: Captured and wrote 0.242 MB perf.data.kvm ]

# perf kvm --guest --host report --stdio
Warning:
1 unprocessable samples recorded.
Do you have a KVM guest running and not using 'perf kvm'?
Error:
The perf.data.kvm file has no samples!
# To display the perf.data header info, please use --header/--header-only 
options.
#

In addition, we used perf to collect hardware performance counters, not the 
symbols, kernel functions, or other stuffs. Thus, what we really need is that 
we need to separate the hardware counters by each domain if it’s possible (i.e. 
we want to verify some counters are from Dom0, other counters are from Dom1, 
and the others come from Dom2, etc.)

I’m pretty much sure that the code you used to distinguish each domain from 
samples will work. I wonder if you can agree with that.

Best,
Sanghyun.

On Aug 29, 2016, at 6:37 PM, Boris Ostrovsky 
> wrote:

On 08/29/2016 05:48 PM, Sanghyun Hong wrote:
I really appreciate for your answers. Last but not the least, I want to make it 
more clear:

The hypervisor will provide dom0 with a raw sample (guest's, dom0's or
hypervisor's) and then it's the job of dom0 kernel to properly tag and
format it and make it available to the userland (i.e. perf itself).
Does this mean if I run the perf command on Dom0 while other domains are 
running, we can collect the performance counter values without distinguishing 
each domain, right?

With 'self' mode each domain collects samples only for itself.

And for 'all' mode apparently this kind of works. With perf build from
Linux 4.7 tree:

root@haswell> xl vcpu-list
NameID  VCPU   CPU State   Time(s)
Affinity (Hard / Soft)
Domain-0 0 00   -b-  55.0  0 / all
Domain-0 0 11   r--  35.9  1 / all
Domain-0 0 22   -b-  36.9  2 / all
Domain-0 0 33   -b-  36.2  3 / all
fedora   1 01   -b- 183.7  1 / all
root@haswell> ./perf kvm --guest --host --guestkallsyms=/tmp/kallsyms
record -C 1 sleep 1
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.139 MB perf.data.kvm (60 samples) ]
root@haswell> ./perf kvm --guest --host --guestkallsyms=/tmp/kallsyms
report --stdio
...
# Overhead  Command  Shared Object
Symbol
#   ...  ...
.
#
   14.48%  swapper  [unknown][k] 0x82d0801c7a37
6.06%  swapper  [kernel.kallsyms][k]
update_blocked_averages
4.38%  swapper  [unknown][k] 0x82d08013690f
2.75%  swapper  [kernel.kallsyms][k] update_rq_clock
2.34%  swapper  [kernel.kallsyms][k] irq_enter
2.33%  [guest/0][guest.kernel.kallsyms]  [g]
fb_pad_aligned_buffer
2.24%  1.hda-0  [kernel.kallsyms][k]
_raw_spin_unlock_irqrestore
2.11%  [guest/0][guest.kernel.kallsyms]  [g] native_safe_halt
2.05%  [guest/0][guest.kernel.kallsyms]  [g]
update_blocked_averages
...

"unknown" samples are from hypervisor.

The tool will then look at the tag and display the event as belonging to
host (dom0, really) or guest. This is supported for KVM, with 'perf kvm'
commands.

So if you can run perf kvm commands then you may be able to
differentiate dom0's and guest's samples (you will also see hypervisor
samples but they won't get resolved to symbols). I am just not sure per
kvm will run on a non-KVM host. I had a private copy where it did but
this was based on a fairly old version of Linux.

(Also, stack profiling is not supported at all).

I wonder if you can share the private copy of your code. I’m looking into the 
source code of the patches, and it seems there’s a way to do it. Even if your 
codes are outdated, I think I can manage to port it. I will promise once I 
finish the porting, I will share my adjustment of your code as well.

Looks like you may not need it.

-boris

Best,
Sanghyun.

On Aug 29, 2016, at 5:24 PM, Boris Ostrovsky 
> wrote:

On 08/29/2016 05:08 PM, Sanghyun Hong wrote:
Yes, this will allow the hypervisor to collect samples from multiple
guests. However, the tool (perf) probably won't be able to properly
process these samples. But you can try.
I understand, thus, I applied

Re: [Xen-devel] Questions about Using Perf at Dom0

I really appreciate for your answers. Last but not the least, I want to make it 
more clear:

> The hypervisor will provide dom0 with a raw sample (guest's, dom0's or
> hypervisor's) and then it's the job of dom0 kernel to properly tag and
> format it and make it available to the userland (i.e. perf itself).

Does this mean if I run the perf command on Dom0 while other domains are 
running, we can collect the performance counter values without distinguishing 
each domain, right?

> The tool will then look at the tag and display the event as belonging to
> host (dom0, really) or guest. This is supported for KVM, with 'perf kvm'
> commands.
> 
> So if you can run perf kvm commands then you may be able to
> differentiate dom0's and guest's samples (you will also see hypervisor
> samples but they won't get resolved to symbols). I am just not sure per
> kvm will run on a non-KVM host. I had a private copy where it did but
> this was based on a fairly old version of Linux.
> 
> (Also, stack profiling is not supported at all).


I wonder if you can share the private copy of your code. I’m looking into the 
source code of the patches, and it seems there’s a way to do it. Even if your 
codes are outdated, I think I can manage to port it. I will promise once I 
finish the porting, I will share my adjustment of your code as well.

Best,
Sanghyun.


> On Aug 29, 2016, at 5:24 PM, Boris Ostrovsky  
> wrote:
> 
> On 08/29/2016 05:08 PM, Sanghyun Hong wrote:
>>> Yes, this will allow the hypervisor to collect samples from multiple
>>> guests. However, the tool (perf) probably won't be able to properly
>>> process these samples. But you can try.
>> 
>> I understand, thus, I applied the patches and set
>> the /pmu_mode/ to *all*. However, I’m really curious what you mean by
>> the tool (*perf*) probably won’t be able to properly process these
>> samples. Is there any things I have to have in mind while collecting
>> the counters, or will it have incorrect values of the counters?
> 
> The hypervisor will provide dom0 with a raw sample (guest's, dom0's or
> hypervisor's) and then it's the job of dom0 kernel to properly tag and
> format it and make it available to the userland (i.e. perf itself). The
> tool will then look at the tag and display the event as belonging to
> host (dom0, really) or guest. This is supported for KVM, with 'perf kvm'
> commands.
> 
> So if you can run perf kvm commands then you may be able to
> differentiate dom0's and guest's samples (you will also see hypervisor
> samples but they won't get resolved to symbols). I am just not sure per
> kvm will run on a non-KVM host. I had a private copy where it did but
> this was based on a fairly old version of Linux.
> 
> (Also, stack profiling is not supported at all).
> 
>> 
>>> You will want to run dom0 on all physical processors (i.e. no
>>> dom0_max_vcpus boot option) and pin all VCPUs for both dom0 and the
>>> guest.
>> 
>> Sure, thanks! My machine has four physical cores, and I’ve set
>> the /dom0_max_vcpus=4/. I think it will have the same effect in
>> removing the /dom0_max_vcpus/ option.
> 
> Yes.
> 
> -boris
> 
>> 
>> Best,
>> Sanghyun.
>> 
>> 
>>> On Aug 29, 2016, at 4:59 PM, Boris Ostrovsky
>>> > wrote:
>>> 
>>> On 08/29/2016 02:42 PM, Sanghyun Hong wrote:
 Hi Boris,
 
 I’ve found the
 documentations(https://github.com/torvalds/linux/blob/master/Documentation/ABI/testing/sysfs-hypervisor-pmu)
 in the kernel source code, and it seems like if we change the mode
 from *self* to *all* then we can collect counters for all the domains,
 right?
>>> 
>>> Yes, this will allow the hypervisor to collect samples from multiple
>>> guests. However, the tool (perf) probably won't be able to properly
>>> process these samples. But you can try.
>>> 
>>> You will want to run dom0 on all physical processors (i.e. no
>>> dom0_max_vcpus boot option) and pin all VCPUs for both dom0 and the
>>> guest.
>>> 
>>> 
>>> -boris
>>> 
 
 All the best,
 Sanghyun.
 
 
> On Aug 29, 2016, at 12:36 PM, Boris Ostrovsky
> 
> > wrote:
> 
> On 08/29/2016 09:18 AM, Sanghyun Hong wrote:
>> Dear Xen-Devel Community:
>> 
>> I’m a grad student working on measuring performance counters at the
>> Xen domains. I read this
>> thread(https://wiki.xenproject.org/wiki/Xen_Profiling:_oprofile_and_perf)
>> in
>> web, and it says using Linux perf command will let us collecting
>> performance counters in both dom0 and domU. Does it mean that we can
>> collect both of them at once if we run perf command on the dom0? (If
>> not, does it mean we can collect counters for each domain separately
>> once we run the perf command in each domain?
> 
> Profiling both guest and dom0 (and the hypervisor)

Re: [Xen-devel] Questions about Using Perf at Dom0

Hi Boris,

I’ve found the 
documentations(https://github.com/torvalds/linux/blob/master/Documentation/ABI/testing/sysfs-hypervisor-pmu)
 in the kernel source code, and it seems like if we change the mode from self 
to all then we can collect counters for all the domains, right?

All the best,
Sanghyun.


On Aug 29, 2016, at 12:36 PM, Boris Ostrovsky 
> wrote:

On 08/29/2016 09:18 AM, Sanghyun Hong wrote:
Dear Xen-Devel Community:

I’m a grad student working on measuring performance counters at the
Xen domains. I read this
thread(https://wiki.xenproject.org/wiki/Xen_Profiling:_oprofile_and_perf) in
web, and it says using Linux perf command will let us collecting
performance counters in both dom0 and domU. Does it mean that we can
collect both of them at once if we run perf command on the dom0? (If
not, does it mean we can collect counters for each domain separately
once we run the perf command in each domain?

Profiling both guest and dom0 (and the hypervisor) requires changes to
perf and those are not there yet.

But you can run perf in each guest (including dom0) separately. Make
sure you have vpmu=true boot option.

-boris






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

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

2016-08-29 Thread osstest service owner

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf e53f1e253e01026029f5ce7474a9d8421c8a0fbb
baseline version:
 ovmf 37136e069dc0a0b8a47098d80d8f6f742db88c04

Last test of basis   100653  2016-08-29 07:45:04 Z0 days
Testing same since   100656  2016-08-30 01:45:45 Z0 days1 attempts


People who touched revisions under test:
  Giri P Mudusuru 
  Jiewen Yao 

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=e53f1e253e01026029f5ce7474a9d8421c8a0fbb
+ . ./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 
e53f1e253e01026029f5ce7474a9d8421c8a0fbb
+ branch=ovmf
+ revision=e53f1e253e01026029f5ce7474a9d8421c8a0fbb
+ . ./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.7-testing
+ '[' xe53f1e253e01026029f5ce7474a9d8421c8a0fbb = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo

Re: [Xen-devel] [PATCH v4 07/16] libxl/arm: Construct ACPI GTDT table



On 2016/8/30 2:16, Julien Grall wrote:
> On 16/08/2016 06:25, Shannon Zhao wrote:
>> From: Shannon Zhao 
>>
>> Construct GTDT table with the interrupt information of timers.
>>
>> Signed-off-by: Shannon Zhao 
>> ---
>>  tools/libxl/libxl_arm_acpi.c | 29 +
>>  1 file changed, 29 insertions(+)
>>
>> diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
>> index 8cd1d9b..28fb6fe 100644
>> --- a/tools/libxl/libxl_arm_acpi.c
>> +++ b/tools/libxl/libxl_arm_acpi.c
>> @@ -24,10 +24,18 @@ typedef uint8_t u8;
>>  typedef uint16_t u16;
>>  typedef uint32_t u32;
>>  typedef uint64_t u64;
>> +typedef int64_t s64;
>>
>>  #include 
>>  #include 
>>
>> +#include 
>> +#define ACPI_MACHINE_WIDTH __BITS_PER_LONG
>> +#define COMPILER_DEPENDENT_INT64 int64_t
>> +#define COMPILER_DEPENDENT_UINT64 uint64_t
>> +
>> +#include 
>> +
>>  _hidden
>>  extern const unsigned char dsdt_anycpu_arm[];
>>  _hidden
>> @@ -175,6 +183,26 @@ static void make_acpi_xsdt(libxl__gc *gc, struct
>> xc_dom_image *dom,
>> acpitables[XSDT].size);
>>  }
>>
>> +static void make_acpi_gtdt(libxl__gc *gc, struct xc_dom_image *dom,
>> +   struct acpitable acpitables[])
>> +{
>> +uint64_t offset = acpitables[GTDT].addr - GUEST_ACPI_BASE;
>> +struct acpi_table_gtdt *gtdt = (void *)dom->acpi_modules[0].data
>> + offset;
>> +
>> +gtdt->non_secure_el1_interrupt = GUEST_TIMER_PHYS_NS_PPI;
>> +gtdt->non_secure_el1_flags =
>> + (ACPI_LEVEL_SENSITIVE <<
>> ACPI_GTDT_INTERRUPT_MODE)
>> + |(ACPI_ACTIVE_LOW <<
>> ACPI_GTDT_INTERRUPT_POLARITY);
>> +gtdt->virtual_timer_interrupt = GUEST_TIMER_VIRT_PPI;
>> +gtdt->virtual_timer_flags =
>> + (ACPI_LEVEL_SENSITIVE <<
>> ACPI_GTDT_INTERRUPT_MODE)
>> + |(ACPI_ACTIVE_LOW <<
>> ACPI_GTDT_INTERRUPT_POLARITY);
>> +
> 
> I don't see any setting for the field counter_block_address. From the
> ACPI spec, the field should be 0x when the counter
> control block is not available
Oops, will add. Thanks.

-- 
Shannon


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

Re: [Xen-devel] [PATCH v4 14/16] public/hvm/params.h: Add macros for HVM_PARAM_CALLBACK_TYPE_PPI



On 2016/8/30 3:00, Julien Grall wrote:
> Hi Shannon,
> 
> On 16/08/2016 06:25, Shannon Zhao wrote:
>> From: Shannon Zhao 
>>
>> Add macros for HVM_PARAM_CALLBACK_TYPE_PPI operation values and update
>> them in evtchn_fixup().
>>
>> Signed-off-by: Shannon Zhao 
>> ---
>>  xen/arch/arm/domain_build.c | 8 +---
>>  xen/include/public/hvm/params.h | 4 
>>  2 files changed, 9 insertions(+), 3 deletions(-)
>>
>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
>> index 60db9e4..94cd3ce 100644
>> --- a/xen/arch/arm/domain_build.c
>> +++ b/xen/arch/arm/domain_build.c
>> @@ -2019,9 +2019,11 @@ static void evtchn_fixup(struct domain *d,
>> struct kernel_info *kinfo)
>> d->arch.evtchn_irq);
>>
>>  /* Set the value of domain param HVM_PARAM_CALLBACK_IRQ */
>> -val = (u64)HVM_PARAM_CALLBACK_TYPE_PPI << 56;
>> -val |= (2 << 8); /* Active-low level-sensitive  */
>> -val |= d->arch.evtchn_irq & 0xff;
>> +val = (u64)HVM_PARAM_CALLBACK_TYPE_PPI <<
>> HVM_PARAM_CALLBACK_IRQ_TYPE_SHIFT;
>> +/* Active-low level-sensitive  */
>> +val |= (HVM_PARAM_CALLBACK_TYPE_PPI_FLAG_LOW_LEVEL <<
>> +HVM_PARAM_CALLBACK_TYPE_PPI_FLAG_SHIFT);
>> +val |= d->arch.evtchn_irq & HVM_PARAM_CALLBACK_TYPE_PPI_MASK;
> 
> The mask is pointless and a call to make things much worse if evtchn_irq
> is not a PPI (which will never happen).
> 
>>  d->arch.hvm_domain.params[HVM_PARAM_CALLBACK_IRQ] = val;
>>
>>  /*
>> diff --git a/xen/include/public/hvm/params.h
>> b/xen/include/public/hvm/params.h
>> index f7338a3..8a0327d 100644
>> --- a/xen/include/public/hvm/params.h
>> +++ b/xen/include/public/hvm/params.h
>> @@ -30,6 +30,7 @@
>>   */
>>
>>  #define HVM_PARAM_CALLBACK_IRQ 0
>> +#define HVM_PARAM_CALLBACK_IRQ_TYPE_SHIFT 56
>>  /*
>>   * How should CPU0 event-channel notifications be delivered?
>>   *
>> @@ -66,6 +67,9 @@
>>   * This is only used by ARM/ARM64 and masking/eoi the interrupt
>> associated to
>>   * the notification is handled by the interrupt controller.
>>   */
>> +#define HVM_PARAM_CALLBACK_TYPE_PPI_FLAG_SHIFT 8
>> +#define HVM_PARAM_CALLBACK_TYPE_PPI_FLAG_LOW_LEVEL 2
>> +#define HVM_PARAM_CALLBACK_TYPE_PPI_MASK   0xff
> 
> Please drop the PPI_MASK, it is not correctly defined (there is only 16
> PPI going from 16 - 32) and pointless.
> 
Sure. Thanks.

-- 
Shannon


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

Re: [Xen-devel] [PATCH v4 16/16] libxl/arm: Add the size of ACPI tables to maxmem



On 2016/8/30 3:07, Julien Grall wrote:
> Hi Shannon,
> 
> On 16/08/2016 06:25, Shannon Zhao wrote:
>> From: Shannon Zhao 
>>
>> While it defines the maximum size of guest ACPI tables in guest
>> memory layout, here it adds the size to set the target maxmem
>> to avoid providing less available memory for guest.
>>
>> Signed-off-by: Shannon Zhao 
>> ---
>>  tools/libxl/libxl_arm.c | 11 +++
>>  1 file changed, 11 insertions(+)
>>
>> diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
>> index d436167..75b2589 100644
>> --- a/tools/libxl/libxl_arm.c
>> +++ b/tools/libxl/libxl_arm.c
>> @@ -103,6 +103,17 @@ int libxl__arch_domain_save_config(libxl__gc *gc,
>>  int libxl__arch_domain_create(libxl__gc *gc, libxl_domain_config
>> *d_config,
>>uint32_t domid)
>>  {
>> +libxl_domain_build_info *const info = _config->b_info;
>> +libxl_ctx *ctx = libxl__gc_owner(gc);
>> +
>> +/* Add the size of ACPI tables to maxmem if ACPI is enabled for
>> guest. */
>> +if (libxl_defbool_val(info->acpi) &&
>> +xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb +
>> +LIBXL_MAXMEM_CONSTANT + GUEST_ACPI_SIZE / 1024) < 0) {
> 
> Why can't we use the estimate size here? It would be better than
> increasing by a constant again the max size (I doubt the ACPI tables
> will be 2MB every time).
> 
The estimate action happens after libxl__arch_domain_create(), I think.
So it can't get the estimate size here.

Also, it's better to add the max size so that it doesn't have to change
here when it adds other contents to the ACPI tables.

Thanks,
-- 
Shannon


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

Re: [Xen-devel] [PATCH v4 05/16] libxl/arm: Construct ACPI RSDP table



On 2016/8/30 2:05, Julien Grall wrote:
> Hi Shannon,
> 
> On 25/08/2016 04:05, Shannon Zhao wrote:
>>
>>
>> On 2016/8/24 20:52, Wei Liu wrote:
>>> On Tue, Aug 16, 2016 at 06:25:02PM +0800, Shannon Zhao wrote:
> From: Shannon Zhao 
>
> Construct ACPI RSDP table and add a helper to calculate the ACPI table
> checksum.
>
> Signed-off-by: Shannon Zhao 
> ---
>  tools/libxl/libxl_arm_acpi.c | 38
> ++
>  1 file changed, 38 insertions(+)
>
> diff --git a/tools/libxl/libxl_arm_acpi.c
> b/tools/libxl/libxl_arm_acpi.c
> index 6be9eb0..9432e44 100644
> --- a/tools/libxl/libxl_arm_acpi.c
> +++ b/tools/libxl/libxl_arm_acpi.c
> @@ -33,6 +33,9 @@ extern const unsigned char dsdt_anycpu_arm[];
>  _hidden
>  extern const int dsdt_anycpu_arm_len;
>
> +#define ACPI_BUILD_APPNAME6 "XenARM"
> +#define ACPI_BUILD_APPNAME4 "Xen "
> +
>>> Where do these come from? If they are from a spec, could you please add
>>> a comment here?
>>>
>> Not from some spec. Just fake a OEM for these tables like the
>> ACPI_OEM_ID, ACPI_CREATOR_ID used by x86.
> 
> In this case, why don't we re-use the one from x86?
> 
While the ACPI_OEM_TABLE_ID and ACPI_CREATOR_ID of x86 are HVM specific,
I don't think it's proper for ARM.

Thanks,
-- 
Shannon


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

Re: [Xen-devel] [PATCH v4 14/16] public/hvm/params.h: Add macros for HVM_PARAM_CALLBACK_TYPE_PPI


Hi Shannon,

On 16/08/2016 06:25, Shannon Zhao wrote:

From: Shannon Zhao 

Add macros for HVM_PARAM_CALLBACK_TYPE_PPI operation values and update
them in evtchn_fixup().

Signed-off-by: Shannon Zhao 
---
 xen/arch/arm/domain_build.c | 8 +---
 xen/include/public/hvm/params.h | 4 
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 60db9e4..94cd3ce 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2019,9 +2019,11 @@ static void evtchn_fixup(struct domain *d, struct 
kernel_info *kinfo)
d->arch.evtchn_irq);

 /* Set the value of domain param HVM_PARAM_CALLBACK_IRQ */
-val = (u64)HVM_PARAM_CALLBACK_TYPE_PPI << 56;
-val |= (2 << 8); /* Active-low level-sensitive  */
-val |= d->arch.evtchn_irq & 0xff;
+val = (u64)HVM_PARAM_CALLBACK_TYPE_PPI << 
HVM_PARAM_CALLBACK_IRQ_TYPE_SHIFT;
+/* Active-low level-sensitive  */
+val |= (HVM_PARAM_CALLBACK_TYPE_PPI_FLAG_LOW_LEVEL <<
+HVM_PARAM_CALLBACK_TYPE_PPI_FLAG_SHIFT);
+val |= d->arch.evtchn_irq & HVM_PARAM_CALLBACK_TYPE_PPI_MASK;


The mask is pointless and a call to make things much worse if evtchn_irq 
is not a PPI (which will never happen).



 d->arch.hvm_domain.params[HVM_PARAM_CALLBACK_IRQ] = val;

 /*
diff --git a/xen/include/public/hvm/params.h b/xen/include/public/hvm/params.h
index f7338a3..8a0327d 100644
--- a/xen/include/public/hvm/params.h
+++ b/xen/include/public/hvm/params.h
@@ -30,6 +30,7 @@
  */

 #define HVM_PARAM_CALLBACK_IRQ 0
+#define HVM_PARAM_CALLBACK_IRQ_TYPE_SHIFT 56
 /*
  * How should CPU0 event-channel notifications be delivered?
  *
@@ -66,6 +67,9 @@
  * This is only used by ARM/ARM64 and masking/eoi the interrupt associated to
  * the notification is handled by the interrupt controller.
  */
+#define HVM_PARAM_CALLBACK_TYPE_PPI_FLAG_SHIFT 8
+#define HVM_PARAM_CALLBACK_TYPE_PPI_FLAG_LOW_LEVEL 2
+#define HVM_PARAM_CALLBACK_TYPE_PPI_MASK   0xff


Please drop the PPI_MASK, it is not correctly defined (there is only 16 
PPI going from 16 - 32) and pointless.



 #endif

 /*



Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v4 12/16] libxl/arm: Factor finalise_one_memory_node as a gerneric function


Hi Shannon,

On 16/08/2016 06:25, Shannon Zhao wrote:

From: Shannon Zhao 

Rename finalise_one_memory_node to finalise_one_node and pass the node
name via function parameter.

This is useful for adding ACPI module which will be added by a later
patch.

Signed-off-by: Shannon Zhao 


Acked-by: Julien Grall 

Regards,


---
 tools/libxl/libxl_arm.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index fa0497c..b95fdf5 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -904,11 +904,11 @@ out:
 return rc;
 }

-static void finalise_one_memory_node(libxl__gc *gc, void *fdt,
- uint64_t base, uint64_t size)
+static void finalise_one_node(libxl__gc *gc, void *fdt, const char *uname,
+  uint64_t base, uint64_t size)
 {
 int node, res;
-const char *name = GCSPRINTF("/memory@%"PRIx64, base);
+const char *name = GCSPRINTF("%s@%"PRIx64, uname, base);

 node = fdt_path_offset(fdt, name);
 assert(node > 0);
@@ -971,7 +971,7 @@ int libxl__arch_domain_finalise_hw_description(libxl__gc 
*gc,
 for (i = 0; i < GUEST_RAM_BANKS; i++) {
 const uint64_t size = (uint64_t)dom->rambank_size[i] << XC_PAGE_SHIFT;

-finalise_one_memory_node(gc, fdt, bankbase[i], size);
+finalise_one_node(gc, fdt, "/memory", bankbase[i], size);
 }

 debug_dump_fdt(gc, fdt);



--
Julien Grall

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

Re: [Xen-devel] [PATCH v4 09/16] libxl/arm: Construct ACPI MADT table




On 16/08/2016 06:25, Shannon Zhao wrote:

From: Shannon Zhao 

According to the GIC version, construct the MADT table.

Signed-off-by: Shannon Zhao 
---
 tools/libxl/libxl_arm_acpi.c | 84 
 1 file changed, 84 insertions(+)

diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
index 28fb6fe..75dfcc2 100644
--- a/tools/libxl/libxl_arm_acpi.c
+++ b/tools/libxl/libxl_arm_acpi.c
@@ -203,6 +203,89 @@ static void make_acpi_gtdt(libxl__gc *gc, struct 
xc_dom_image *dom,
acpitables[GTDT].size);
 }

+static void make_acpi_madt_gicc(void *table, int nr_cpus, uint64_t gicc_base)
+{
+uint32_t i;


Please don't mix the type. Either i should be int or nr_cpus uint32_t.


+struct acpi_madt_generic_interrupt *gicc = table;
+
+for (i = 0; i < nr_cpus; i++) {
+gicc->header.type = ACPI_MADT_TYPE_GENERIC_INTERRUPT;
+gicc->header.length = sizeof(*gicc);
+gicc->base_address = gicc_base;
+gicc->cpu_interface_number = i;
+gicc->arm_mpidr = libxl__compute_mpdir(i);
+gicc->uid = i;
+gicc->flags = ACPI_MADT_ENABLED;
+gicc++;
+}
+}


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v4 16/16] libxl/arm: Add the size of ACPI tables to maxmem


Hi Shannon,

On 16/08/2016 06:25, Shannon Zhao wrote:

From: Shannon Zhao 

While it defines the maximum size of guest ACPI tables in guest
memory layout, here it adds the size to set the target maxmem
to avoid providing less available memory for guest.

Signed-off-by: Shannon Zhao 
---
 tools/libxl/libxl_arm.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index d436167..75b2589 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -103,6 +103,17 @@ int libxl__arch_domain_save_config(libxl__gc *gc,
 int libxl__arch_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
   uint32_t domid)
 {
+libxl_domain_build_info *const info = _config->b_info;
+libxl_ctx *ctx = libxl__gc_owner(gc);
+
+/* Add the size of ACPI tables to maxmem if ACPI is enabled for guest. */
+if (libxl_defbool_val(info->acpi) &&
+xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb +
+LIBXL_MAXMEM_CONSTANT + GUEST_ACPI_SIZE / 1024) < 0) {


Why can't we use the estimate size here? It would be better than 
increasing by a constant again the max size (I doubt the ACPI tables 
will be 2MB every time).


Also, this looks like quite unsafe. If someone decides to change the 
default size, (s)he would have to replicate the new algo here.


Wei, Ian, do you have any suggestion to avoid duplication?


+LOGE(ERROR, "Couldn't set max memory");
+return ERROR_FAIL;
+}
+
 return 0;
 }




Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v4 00/16] Xen ARM DomU ACPI support


Hi Wei,

On 24/08/2016 08:58, Wei Liu wrote:

On Tue, Aug 16, 2016 at 06:24:57PM +0800, Shannon Zhao wrote:

From: Shannon Zhao 

The design of this feature is described as below.
Firstly, the toolstack (libxl) generates the ACPI tables according the
number of vcpus and gic controller.

Then, it copies these ACPI tables to DomU non-RAM memory map space and
passes them to UEFI firmware through the "ARM multiboot" protocol.

At last, UEFI gets the ACPI tables through the "ARM multiboot" protocol
and installs these tables like the usual way and passes both ACPI and DT
information to the Xen DomU.

Currently libxl only generates RSDP, XSDT, GTDT, MADT, FADT, DSDT tables
since it's enough now.

This has been tested using guest kernel with the Dom0 ACPI support
patches which could be fetched from linux master or:
https://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/log/?h=efi/arm-xen

The UEFI binary could be fetched from or built from edk2 master branch:
http://people.linaro.org/~shannon.zhao/DomU_ACPI/XEN_EFI.fd

This series can be fetched from:
https://git.linaro.org/people/shannon.zhao/xen.git  domu_acpi_v4



Thanks for posting this version and sorry for the late review.

I've skimmed the whole series and pointed out things I think should be
improved. I will leave reviewing all the table building code to ARM
maintainers.


I looked at the tables, they look good to me. Although, I made few 
comments on various place.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v4 05/16] libxl/arm: Construct ACPI RSDP table


Hi Shannon,

On 25/08/2016 04:05, Shannon Zhao wrote:



On 2016/8/24 20:52, Wei Liu wrote:

On Tue, Aug 16, 2016 at 06:25:02PM +0800, Shannon Zhao wrote:

From: Shannon Zhao 

Construct ACPI RSDP table and add a helper to calculate the ACPI table
checksum.

Signed-off-by: Shannon Zhao 
---
 tools/libxl/libxl_arm_acpi.c | 38 ++
 1 file changed, 38 insertions(+)

diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
index 6be9eb0..9432e44 100644
--- a/tools/libxl/libxl_arm_acpi.c
+++ b/tools/libxl/libxl_arm_acpi.c
@@ -33,6 +33,9 @@ extern const unsigned char dsdt_anycpu_arm[];
 _hidden
 extern const int dsdt_anycpu_arm_len;

+#define ACPI_BUILD_APPNAME6 "XenARM"
+#define ACPI_BUILD_APPNAME4 "Xen "
+

Where do these come from? If they are from a spec, could you please add
a comment here?


Not from some spec. Just fake a OEM for these tables like the
ACPI_OEM_ID, ACPI_CREATOR_ID used by x86.


In this case, why don't we re-use the one from x86?

Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v4 13/16] libxl/arm: Add ACPI module


Hi Shannon,

On 16/08/2016 06:25, Shannon Zhao wrote:

From: Shannon Zhao 

Add the ARM Multiboot module for ACPI, so UEFI or DomU can get the base
address of ACPI tables from it.

Signed-off-by: Shannon Zhao 


Acked-by: Julien Grall 


---
 docs/misc/arm/device-tree/acpi.txt | 24 
 tools/libxl/libxl_arm.c| 24 
 2 files changed, 48 insertions(+)
 create mode 100644 docs/misc/arm/device-tree/acpi.txt

diff --git a/docs/misc/arm/device-tree/acpi.txt 
b/docs/misc/arm/device-tree/acpi.txt
new file mode 100644
index 000..3e70157
--- /dev/null
+++ b/docs/misc/arm/device-tree/acpi.txt
@@ -0,0 +1,24 @@
+DomU ACPI module
+
+
+Xen toolstack passes the domU ACPI tables via a reference in the /chosen node 
of
+the device tree.
+
+Each node contains the following properties:
+
+- compatible
+
+   "xen,guest-acpi", "multiboot,module"
+
+- reg
+
+   Specifies the physical address and the length of the module.
+   RSDP table is always located at the beginning of this region.
+
+Examples
+
+
+   module@0x2000 {
+   compatible = "xen,guest-acpi", "multiboot,module";
+   reg = <0x2000 0x1234>;
+   };
diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index b95fdf5..11a6f6e 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -285,6 +285,25 @@ static int make_chosen_node(libxl__gc *gc, void *fdt, bool 
ramdisk,
 if (res) return res;
 }

+if (libxl_defbool_val(info->acpi)) {
+const uint64_t acpi_base = GUEST_ACPI_BASE;
+const char *name = GCSPRINTF("module@%"PRIx64, acpi_base);
+
+res = fdt_begin_node(fdt, name);
+if (res) return res;
+
+res = fdt_property_compat(gc, fdt, 2, "xen,guest-acpi",
+  "multiboot,module");
+if (res) return res;
+
+res = fdt_property_regs(gc, fdt, ROOT_ADDRESS_CELLS, ROOT_SIZE_CELLS,
+1, 0, 0);
+if (res) return res;
+
+res = fdt_end_node(fdt);
+if (res) return res;
+}
+
 res = fdt_end_node(fdt);
 if (res) return res;

@@ -974,6 +993,11 @@ int libxl__arch_domain_finalise_hw_description(libxl__gc 
*gc,
 finalise_one_node(gc, fdt, "/memory", bankbase[i], size);
 }

+if (dom->acpi_modules[0].data) {
+finalise_one_node(gc, fdt, "/chosen/module", GUEST_ACPI_BASE,
+  dom->acpi_modules[0].length);
+}
+
 debug_dump_fdt(gc, fdt);

 return 0;



Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v4 10/16] libxl/arm: Construct ACPI FADT table


Hi Shannon,

On 16/08/2016 06:25, Shannon Zhao wrote:

From: Shannon Zhao 

Signed-off-by: Shannon Zhao 
---
 tools/libxl/libxl_arm_acpi.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
index 75dfcc2..cb1c9df 100644
--- a/tools/libxl/libxl_arm_acpi.c
+++ b/tools/libxl/libxl_arm_acpi.c
@@ -286,6 +286,25 @@ out:
 return rc;
 }

+static void make_acpi_fadt(libxl__gc *gc, struct xc_dom_image *dom,
+   struct acpitable acpitables[])
+{
+uint64_t offset = acpitables[FADT].addr - GUEST_ACPI_BASE;
+struct acpi_table_fadt *fadt = (void *)dom->acpi_modules[0].data + offset;
+
+/* Hardware Reduced = 1 and use PSCI 0.2+ and with HVC */
+fadt->flags = ACPI_FADT_HW_REDUCED;
+fadt->arm_boot_flags = (ACPI_FADT_PSCI_COMPLIANT) | ACPI_FADT_PSCI_USE_HVC;


NIT: The () are not necessary for ACPI_FADT_PSCI_COMPLIANT


+
+/* ACPI v5.1 (fadt->revision.fadt->minor_revision) */
+fadt->minor_revision = 0x1;
+fadt->dsdt = acpitables[DSDT].addr;
+
+make_acpi_header(>header, "FACP", acpitables[FADT].size, 5);
+calculate_checksum(fadt, offsetof(struct acpi_table_header, checksum),
+   acpitables[FADT].size);
+}
+
 int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
 libxl__domain_build_state *state,
 struct xc_dom_image *dom)
@@ -318,6 +337,10 @@ int libxl__prepare_acpi(libxl__gc *gc, 
libxl_domain_build_info *info,
 make_acpi_xsdt(gc, dom, acpitables);
 make_acpi_gtdt(gc, dom, acpitables);
 rc = make_acpi_madt(gc, dom, info->max_vcpus, xc_config, acpitables);
+if (rc)
+goto out;
+
+make_acpi_fadt(gc, dom, acpitables);

 out:
 return rc;



Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v4 08/16] libxl/arm: Factor MPIDR computing codes out as a helper


Hi Shannon,

On 16/08/2016 06:25, Shannon Zhao wrote:

From: Shannon Zhao 

Factor MPIDR computing codes out as a helper, so it could be shared
between DT and ACPI.

Signed-off-by: Shannon Zhao 


Acked-by: Julien Grall 

Regards,


---
 tools/libxl/libxl_arm.c |  8 +---
 tools/libxl/libxl_arm.h | 11 +++
 2 files changed, 12 insertions(+), 7 deletions(-)

diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index 8c7fc09..fa0497c 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -309,13 +309,7 @@ static int make_cpus_node(libxl__gc *gc, void *fdt, int 
nr_cpus,
 for (i = 0; i < nr_cpus; i++) {
 const char *name;

-/*
- * According to ARM CPUs bindings, the reg field should match
- * the MPIDR's affinity bits. We will use AFF0 and AFF1 when
- * constructing the reg value of the guest at the moment, for it
- * is enough for the current max vcpu number.
- */
-mpidr_aff = (i & 0x0f) | (((i >> 4) & 0xff) << 8);
+mpidr_aff = libxl__compute_mpdir(i);
 name = GCSPRINTF("cpu@%"PRIx64, mpidr_aff);

 res = fdt_begin_node(fdt, name);
diff --git a/tools/libxl/libxl_arm.h b/tools/libxl/libxl_arm.h
index fe1c05f..5c8fbc6 100644
--- a/tools/libxl/libxl_arm.h
+++ b/tools/libxl/libxl_arm.h
@@ -35,6 +35,17 @@ static inline int libxl__prepare_acpi(libxl__gc *gc,
 }
 #endif

+static inline uint64_t libxl__compute_mpdir(unsigned int cpuid)
+{
+/*
+ * According to ARM CPUs bindings, the reg field should match
+ * the MPIDR's affinity bits. We will use AFF0 and AFF1 when
+ * constructing the reg value of the guest at the moment, for it
+ * is enough for the current max vcpu number.
+ */
+return (cpuid & 0x0f) | (((cpuid >> 4) & 0xff) << 8);
+}
+
 /*
  * Local variables:
  * mode: C



--
Julien Grall

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

Re: [Xen-devel] [PATCH v4 06/16] libxl/arm: Construct ACPI XSDT table


Hi Shannon,

On 16/08/2016 06:25, Shannon Zhao wrote:

From: Shannon Zhao 

Signed-off-by: Shannon Zhao 
---
 tools/libxl/libxl_arm_acpi.c | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
index 9432e44..8cd1d9b 100644
--- a/tools/libxl/libxl_arm_acpi.c
+++ b/tools/libxl/libxl_arm_acpi.c
@@ -146,6 +146,35 @@ static void make_acpi_rsdp(libxl__gc *gc, struct 
xc_dom_image *dom,
acpitables[RSDP].size);
 }

+static void make_acpi_header(struct acpi_table_header *h, const char *sig,
+ int len, uint8_t rev)


len should be size_t.


+{
+memcpy(h->signature, sig, 4);
+h->length = len;
+h->revision = rev;
+memcpy(h->oem_id, ACPI_BUILD_APPNAME6, 6);
+memcpy(h->oem_table_id, ACPI_BUILD_APPNAME4, 4);
+memcpy(h->oem_table_id + 4, sig, 4);
+h->oem_revision = 1;
+memcpy(h->asl_compiler_id, ACPI_BUILD_APPNAME4, 4);
+h->asl_compiler_revision = 1;
+h->checksum = 0;
+}
+
+static void make_acpi_xsdt(libxl__gc *gc, struct xc_dom_image *dom,
+   struct acpitable acpitables[])
+{
+uint64_t offset = acpitables[XSDT].addr - GUEST_ACPI_BASE;
+struct acpi_table_xsdt *xsdt = (void *)dom->acpi_modules[0].data + offset;
+
+xsdt->table_offset_entry[0] = acpitables[MADT].addr;
+xsdt->table_offset_entry[1] = acpitables[GTDT].addr;
+xsdt->table_offset_entry[2] = acpitables[FADT].addr;
+make_acpi_header(>header, "XSDT", acpitables[XSDT].size, 1);
+calculate_checksum(xsdt, offsetof(struct acpi_table_header, checksum),
+   acpitables[XSDT].size);
+}
+
 int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
 libxl__domain_build_state *state,
 struct xc_dom_image *dom)
@@ -175,6 +204,7 @@ int libxl__prepare_acpi(libxl__gc *gc, 
libxl_domain_build_info *info,
 goto out;

 make_acpi_rsdp(gc, dom, acpitables);
+make_acpi_xsdt(gc, dom, acpitables);

 out:
 return rc;



Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v4 05/16] libxl/arm: Construct ACPI RSDP table


Hi Shannon,

On 16/08/2016 06:25, Shannon Zhao wrote:

From: Shannon Zhao 

Construct ACPI RSDP table and add a helper to calculate the ACPI table
checksum.

Signed-off-by: Shannon Zhao 
---
 tools/libxl/libxl_arm_acpi.c | 38 ++
 1 file changed, 38 insertions(+)

diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
index 6be9eb0..9432e44 100644
--- a/tools/libxl/libxl_arm_acpi.c
+++ b/tools/libxl/libxl_arm_acpi.c
@@ -33,6 +33,9 @@ extern const unsigned char dsdt_anycpu_arm[];
 _hidden
 extern const int dsdt_anycpu_arm_len;

+#define ACPI_BUILD_APPNAME6 "XenARM"
+#define ACPI_BUILD_APPNAME4 "Xen "
+
 enum {
 RSDP,
 XSDT,
@@ -112,6 +115,37 @@ out:
 return rc;
 }

+static void calculate_checksum(void *table, uint32_t checksum_offset,
+   uint32_t length)
+{
+uint8_t *p, sum = 0;
+
+p = table;
+p[checksum_offset] = 0;
+
+while ( length-- )
+sum = sum + *p++;
+
+p = table;
+p[checksum_offset] = -sum;
+}
+
+static void make_acpi_rsdp(libxl__gc *gc, struct xc_dom_image *dom,
+   struct acpitable acpitables[])
+{
+uint64_t offset = acpitables[RSDP].addr - GUEST_ACPI_BASE;
+struct acpi_table_rsdp *rsdp = (void *)dom->acpi_modules[0].data + offset;


Why do you cast to (void *)?


+
+memcpy(rsdp->signature, "RSD PTR ", sizeof(rsdp->signature));
+memcpy(rsdp->oem_id, ACPI_BUILD_APPNAME6, sizeof(rsdp->oem_id));
+rsdp->length = acpitables[RSDP].size;
+rsdp->revision = 0x02;
+rsdp->xsdt_physical_address = acpitables[XSDT].addr;
+calculate_checksum(rsdp,
+   offsetof(struct acpi_table_rsdp, extended_checksum),
+   acpitables[RSDP].size);
+}
+
 int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
 libxl__domain_build_state *state,
 struct xc_dom_image *dom)
@@ -137,6 +171,10 @@ int libxl__prepare_acpi(libxl__gc *gc, 
libxl_domain_build_info *info,
 dom->acpi_modules[0].guest_addr_out = GUEST_ACPI_BASE;

 rc = libxl__estimate_acpi_size(gc, info, dom, xc_config, acpitables);
+if (rc)
+goto out;
+
+make_acpi_rsdp(gc, dom, acpitables);

 out:
 return rc;



--
Julien Grall

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

Re: [Xen-devel] [PATCH v4 07/16] libxl/arm: Construct ACPI GTDT table


Hi Shannon,

On 16/08/2016 06:25, Shannon Zhao wrote:

From: Shannon Zhao 

Construct GTDT table with the interrupt information of timers.

Signed-off-by: Shannon Zhao 
---
 tools/libxl/libxl_arm_acpi.c | 29 +
 1 file changed, 29 insertions(+)

diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
index 8cd1d9b..28fb6fe 100644
--- a/tools/libxl/libxl_arm_acpi.c
+++ b/tools/libxl/libxl_arm_acpi.c
@@ -24,10 +24,18 @@ typedef uint8_t u8;
 typedef uint16_t u16;
 typedef uint32_t u32;
 typedef uint64_t u64;
+typedef int64_t s64;

 #include 
 #include 

+#include 
+#define ACPI_MACHINE_WIDTH __BITS_PER_LONG
+#define COMPILER_DEPENDENT_INT64 int64_t
+#define COMPILER_DEPENDENT_UINT64 uint64_t
+
+#include 
+
 _hidden
 extern const unsigned char dsdt_anycpu_arm[];
 _hidden
@@ -175,6 +183,26 @@ static void make_acpi_xsdt(libxl__gc *gc, struct 
xc_dom_image *dom,
acpitables[XSDT].size);
 }

+static void make_acpi_gtdt(libxl__gc *gc, struct xc_dom_image *dom,
+   struct acpitable acpitables[])
+{
+uint64_t offset = acpitables[GTDT].addr - GUEST_ACPI_BASE;
+struct acpi_table_gtdt *gtdt = (void *)dom->acpi_modules[0].data + offset;
+
+gtdt->non_secure_el1_interrupt = GUEST_TIMER_PHYS_NS_PPI;
+gtdt->non_secure_el1_flags =
+ (ACPI_LEVEL_SENSITIVE << ACPI_GTDT_INTERRUPT_MODE)
+ |(ACPI_ACTIVE_LOW << 
ACPI_GTDT_INTERRUPT_POLARITY);
+gtdt->virtual_timer_interrupt = GUEST_TIMER_VIRT_PPI;
+gtdt->virtual_timer_flags =
+ (ACPI_LEVEL_SENSITIVE << ACPI_GTDT_INTERRUPT_MODE)
+ |(ACPI_ACTIVE_LOW << 
ACPI_GTDT_INTERRUPT_POLARITY);
+


I don't see any setting for the field counter_block_address. From the 
ACPI spec, the field should be 0x when the counter 
control block is not available.



+make_acpi_header(>header, "GTDT", acpitables[GTDT].size, 2);
+calculate_checksum(gtdt, offsetof(struct acpi_table_header, checksum),
+   acpitables[GTDT].size);
+}
+
 int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
 libxl__domain_build_state *state,
 struct xc_dom_image *dom)
@@ -205,6 +233,7 @@ int libxl__prepare_acpi(libxl__gc *gc, 
libxl_domain_build_info *info,

 make_acpi_rsdp(gc, dom, acpitables);
 make_acpi_xsdt(gc, dom, acpitables);
+make_acpi_gtdt(gc, dom, acpitables);

 out:
 return rc;



Regards,

--
Julien Grall

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

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

2016-08-29 Thread osstest service owner

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

Failures :-/ but no regressions.

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

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

version targeted for testing:
 xen  81caac0cd0f56b0052a7884e6bd99e3a652ddd59
baseline version:
 xen  8bc02b47e5833c374b35618729d147d2980d4e05

Last test of basis   100650  2016-08-29 01:59:44 Z0 days
Testing same since   100655  2016-08-29 17:14:42 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 
  Suravee Suthikulpanit 

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

Re: [Xen-devel] [PATCH v4 03/16] libxl/arm: Generate static ACPI DSDT table


Hi Shannon,

On 16/08/2016 06:25, Shannon Zhao wrote:

From: Shannon Zhao 

It uses static DSDT table like the way x86 uses. Currently the DSDT
table only contains processor device objects and it generates the
maximal objects which so far is 128.

Also only check iasl for aarch64 in configure since ACPI on ARM32 is not
supported.

Signed-off-by: Shannon Zhao 
---
 tools/configure   |  2 +-


The file tools/configure should not be modified manually. Instead you 
have to modify tools/configure.ac.


You can regenerate tools/configure, you can call ./autegen.sh. However, 
I would recommend you to not include the changes of configure and ask 
the committer to regenerate. This is because we use always use the same 
version of autotools to do generation in order to avoid spurious change.



 tools/libacpi/Makefile| 15 -
 tools/libacpi/mk_dsdt.c   | 51 ---
 tools/libxl/Makefile  |  5 -
 tools/libxl/libxl_arm_acpi.c  |  5 +
 xen/include/public/arch-arm.h |  3 +++
 6 files changed, 65 insertions(+), 16 deletions(-)

diff --git a/tools/configure b/tools/configure
index 5b5dcce..48239c0 100755
--- a/tools/configure
+++ b/tools/configure
@@ -7458,7 +7458,7 @@ then
 as_fn_error $? "Unable to find xgettext, please install xgettext" 
"$LINENO" 5
 fi
 case "$host_cpu" in
-i[3456]86|x86_64)
+i[3456]86|x86_64|aarch64)
 # Extract the first word of "iasl", so it can be a program name with args.
 set dummy iasl; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
diff --git a/tools/libacpi/Makefile b/tools/libacpi/Makefile
index d741ac5..7f50a33 100644
--- a/tools/libacpi/Makefile
+++ b/tools/libacpi/Makefile
@@ -19,6 +19,7 @@ MK_DSDT = $(ACPI_BUILD_DIR)/mk_dsdt

 # Sources to be generated
 C_SRC = $(addprefix $(ACPI_BUILD_DIR)/, dsdt_anycpu.c dsdt_15cpu.c  
dsdt_anycpu_qemu_xen.c dsdt_pvh.c)
+C_SRC += $(ACPI_BUILD_DIR)/dsdt_anycpu_arm.c


Do we really want to generate dsdt_anycpu_arm.c even for x86? Similarly, 
do we want to generate x86 dsdt for ARM?



 H_SRC = $(addprefix $(ACPI_BUILD_DIR)/, ssdt_s3.h ssdt_s4.h ssdt_pm.h 
ssdt_tpm.h)

 vpath iasl $(PATH)
@@ -32,7 +33,7 @@ $(H_SRC): $(ACPI_BUILD_DIR)/%.h: %.asl iasl
cd $(CURDIR)

 $(MK_DSDT): mk_dsdt.c
-   $(HOSTCC) $(HOSTCFLAGS) $(CFLAGS_xeninclude) -o $@ mk_dsdt.c
+   $(HOSTCC) $(HOSTCFLAGS) $(CFLAGS_xeninclude) -D__XEN_TOOLS__ -o $@ 
mk_dsdt.c


It would be useful to mention either in the code or in the commit 
message why you added __XEN_TOOLS__ here.




 $(ACPI_BUILD_DIR)/dsdt_anycpu_qemu_xen.asl: dsdt.asl dsdt_acpi_info.asl 
$(MK_DSDT)
awk 'NR > 1 {print s} {s=$$0}' $< > $@
@@ -62,6 +63,18 @@ $(ACPI_BUILD_DIR)/dsdt_pvh.c: iasl 
$(ACPI_BUILD_DIR)/dsdt_pvh.asl
echo "int dsdt_pvh_len=sizeof(dsdt_pvh);" >>$@
rm -f $(ACPI_BUILD_DIR)/$*.aml $(ACPI_BUILD_DIR)/$*.hex

+$(ACPI_BUILD_DIR)/dsdt_anycpu_arm.asl: $(MK_DSDT)
+   printf "DefinitionBlock (\"DSDT.aml\", \"DSDT\", 3, \"XenARM\", \"Xen DSDT\", 
1)\n{" > $@
+   $(MK_DSDT) --debug=$(debug) --arch arm >> $@
+
+$(ACPI_BUILD_DIR)/dsdt_anycpu_arm.c: iasl $(ACPI_BUILD_DIR)/dsdt_anycpu_arm.asl
+   cd $(ACPI_BUILD_DIR)
+   iasl -vs -p $* -tc $(ACPI_BUILD_DIR)/$*.asl
+   sed -e 's/AmlCode/$*/g' $*.hex >$@
+   echo "int $*_len=sizeof($*);" >>$@
+   rm -f $*.aml $*.hex
+   cd $(CURDIR)
+
 iasl:
@echo
@echo "ACPI ASL compiler (iasl) is needed"
diff --git a/tools/libacpi/mk_dsdt.c b/tools/libacpi/mk_dsdt.c
index 7d76784..f3ab28f 100644
--- a/tools/libacpi/mk_dsdt.c
+++ b/tools/libacpi/mk_dsdt.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 


arch-arm.h defines a lot of ARM specific constant. This is a call to 
misused them when built for x86.


Similarly, xen/hvm/hvm_info_table.h should not be included for ARM.



 static unsigned int indent_level;
 static bool debug = false;
@@ -99,6 +100,7 @@ static struct option options[] = {
 { "dm-version", 1, 0, 'q' },
 { "debug", 1, 0, 'd' },
 { "no-dm", 0, 0, 'n' },
+{ "arch", 1, 0, 'a' },
 { 0, 0, 0, 0 }
 };

@@ -106,7 +108,7 @@ int main(int argc, char **argv)
 {
 unsigned int slot, dev, intx, link, cpu, max_cpus = HVM_MAX_VCPUS;


Here an example why we should avoid to include x86 header for ARM. 
HVM_MAX_VCPUS is x86 specific.



 dm_version dm_version = QEMU_XEN_TRADITIONAL;
-bool no_dm = 0;
+bool no_dm = 0, arch_is_arm = false;

 for ( ; ; )
 {
@@ -145,6 +147,10 @@ int main(int argc, char **argv)
 case 'n':
 no_dm = 1;
 break;
+case 'a':
+if (strcmp(optarg, "arm") == 0)
+arch_is_arm = true;
+break;
 case 'd':
 if (*optarg == 'y')
 debug = true;
@@ -154,6 +160,9 @@ int main(int argc, char **argv)
 }
 }

+if (arch_is_arm)
+

Re: [Xen-devel] [PATCH] Fix a BUG_ON issue

2016-08-29 Thread Wu, Feng



> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, August 29, 2016 7:51 PM
> To: Wu, Feng 
> Cc: xen-devel@lists.xen.org
> Subject: Re: [PATCH] Fix a BUG_ON issue
> 
> >>> On 29.08.16 at 11:14,  wrote:
> > --- a/xen/drivers/passthrough/io.c
> > +++ b/xen/drivers/passthrough/io.c
> > @@ -243,7 +243,7 @@ static struct vcpu *vector_hashing_dest(const struct
> domain *d,
> >  for ( i = 0; i <= mod; i++ )
> >  {
> >  idx = find_next_bit(dest_vcpu_bitmap, d->max_vcpus, idx) + 1;
> > -BUG_ON(idx >= d->max_vcpus);
> > +BUG_ON(idx > d->max_vcpus);
> >  }
> >
> >  dest = d->vcpu[idx - 1];
> 
> Wouldn't it be better to change the code to
> 
> unsigned int idx = -1;
> 
> for ( i = 0; i <= mod; i++ )
> {
> idx = find_next_bit(dest_vcpu_bitmap, d->max_vcpus, idx + 1);
> BUG_ON(idx >= d->max_vcpus);
> }
> 
> dest = d->vcpu[idx];

Thanks for the comments, both are good to me, but I slightly prefer this
one. Do I need to send another version?

Thanks,
Feng

> 
> or, not utilizing wrapping
> 
> unsigned int idx = find_first_bit(dest_vcpu_bitmap, d->max_vcpus);
> 
> for ( i = 0; i < mod; i++ )
> idx = find_next_bit(dest_vcpu_bitmap, d->max_vcpus, idx + 1);
> 
> BUG_ON(idx >= d->max_vcpus);
> 
> dest = d->vcpu[idx];
> 
> Jan


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

Re: [Xen-devel] Questions about Using Perf at Dom0

On 08/29/2016 05:48 PM, Sanghyun Hong wrote:
> I really appreciate for your answers. Last but not the least, I want to make 
> it more clear:
>
>> The hypervisor will provide dom0 with a raw sample (guest's, dom0's or
>> hypervisor's) and then it's the job of dom0 kernel to properly tag and
>> format it and make it available to the userland (i.e. perf itself).
> Does this mean if I run the perf command on Dom0 while other domains are 
> running, we can collect the performance counter values without distinguishing 
> each domain, right?

With 'self' mode each domain collects samples only for itself.

And for 'all' mode apparently this kind of works. With perf build from
Linux 4.7 tree:

root@haswell> xl vcpu-list
NameID  VCPU   CPU State   Time(s)
Affinity (Hard / Soft)
Domain-0 0 00   -b-  55.0  0 / all
Domain-0 0 11   r--  35.9  1 / all
Domain-0 0 22   -b-  36.9  2 / all
Domain-0 0 33   -b-  36.2  3 / all
fedora   1 01   -b- 183.7  1 / all
root@haswell> ./perf kvm --guest --host --guestkallsyms=/tmp/kallsyms
record -C 1 sleep 1
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.139 MB perf.data.kvm (60 samples) ]
root@haswell> ./perf kvm --guest --host --guestkallsyms=/tmp/kallsyms
report --stdio
...
# Overhead  Command  Shared Object   
Symbol  
#   ...  ... 
.
#
14.48%  swapper  [unknown][k] 0x82d0801c7a37
 6.06%  swapper  [kernel.kallsyms][k]
update_blocked_averages
 4.38%  swapper  [unknown][k] 0x82d08013690f
 2.75%  swapper  [kernel.kallsyms][k] update_rq_clock
 2.34%  swapper  [kernel.kallsyms][k] irq_enter
 2.33%  [guest/0][guest.kernel.kallsyms]  [g]
fb_pad_aligned_buffer
 2.24%  1.hda-0  [kernel.kallsyms][k]
_raw_spin_unlock_irqrestore
 2.11%  [guest/0][guest.kernel.kallsyms]  [g] native_safe_halt
 2.05%  [guest/0][guest.kernel.kallsyms]  [g]
update_blocked_averages
...

"unknown" samples are from hypervisor.


>
>> The tool will then look at the tag and display the event as belonging to
>> host (dom0, really) or guest. This is supported for KVM, with 'perf kvm'
>> commands.
>>
>> So if you can run perf kvm commands then you may be able to
>> differentiate dom0's and guest's samples (you will also see hypervisor
>> samples but they won't get resolved to symbols). I am just not sure per
>> kvm will run on a non-KVM host. I had a private copy where it did but
>> this was based on a fairly old version of Linux.
>>
>> (Also, stack profiling is not supported at all).
>
> I wonder if you can share the private copy of your code. I’m looking into the 
> source code of the patches, and it seems there’s a way to do it. Even if your 
> codes are outdated, I think I can manage to port it. I will promise once I 
> finish the porting, I will share my adjustment of your code as well.

Looks like you may not need it.

-boris

>
> Best,
> Sanghyun.
>
>
>> On Aug 29, 2016, at 5:24 PM, Boris Ostrovsky  
>> wrote:
>>
>> On 08/29/2016 05:08 PM, Sanghyun Hong wrote:
 Yes, this will allow the hypervisor to collect samples from multiple
 guests. However, the tool (perf) probably won't be able to properly
 process these samples. But you can try.
>>> I understand, thus, I applied the patches and set
>>> the /pmu_mode/ to *all*. However, I’m really curious what you mean by
>>> the tool (*perf*) probably won’t be able to properly process these
>>> samples. Is there any things I have to have in mind while collecting
>>> the counters, or will it have incorrect values of the counters?
>> The hypervisor will provide dom0 with a raw sample (guest's, dom0's or
>> hypervisor's) and then it's the job of dom0 kernel to properly tag and
>> format it and make it available to the userland (i.e. perf itself). The
>> tool will then look at the tag and display the event as belonging to
>> host (dom0, really) or guest. This is supported for KVM, with 'perf kvm'
>> commands.
>>
>> So if you can run perf kvm commands then you may be able to
>> differentiate dom0's and guest's samples (you will also see hypervisor
>> samples but they won't get resolved to symbols). I am just not sure per
>> kvm will run on a non-KVM host. I had a private copy where it did but
>> this was based on a fairly old version of Linux.
>>
>> (Also, stack profiling is not supported at all).
>>
 You will want to run dom0 on all physical processors (i.e. no
 dom0_max_vcpus boot option) and pin all VCPUs for both dom0 and the
 guest.
>>> Sure,

Re: [Xen-devel] Questions about Using Perf at Dom0

On 08/29/2016 05:08 PM, Sanghyun Hong wrote:
>> Yes, this will allow the hypervisor to collect samples from multiple
>> guests. However, the tool (perf) probably won't be able to properly
>> process these samples. But you can try.
>
> I understand, thus, I applied the patches and set
> the /pmu_mode/ to *all*. However, I’m really curious what you mean by
> the tool (*perf*) probably won’t be able to properly process these
> samples. Is there any things I have to have in mind while collecting
> the counters, or will it have incorrect values of the counters?

The hypervisor will provide dom0 with a raw sample (guest's, dom0's or
hypervisor's) and then it's the job of dom0 kernel to properly tag and
format it and make it available to the userland (i.e. perf itself). The
tool will then look at the tag and display the event as belonging to
host (dom0, really) or guest. This is supported for KVM, with 'perf kvm'
commands.

So if you can run perf kvm commands then you may be able to
differentiate dom0's and guest's samples (you will also see hypervisor
samples but they won't get resolved to symbols). I am just not sure per
kvm will run on a non-KVM host. I had a private copy where it did but
this was based on a fairly old version of Linux.

(Also, stack profiling is not supported at all).

>
>> You will want to run dom0 on all physical processors (i.e. no
>> dom0_max_vcpus boot option) and pin all VCPUs for both dom0 and the
>> guest.
>
> Sure, thanks! My machine has four physical cores, and I’ve set
> the /dom0_max_vcpus=4/. I think it will have the same effect in
> removing the /dom0_max_vcpus/ option.

Yes.

-boris

>
> Best,
> Sanghyun.
>
>
>> On Aug 29, 2016, at 4:59 PM, Boris Ostrovsky
>> > wrote:
>>
>> On 08/29/2016 02:42 PM, Sanghyun Hong wrote:
>>> Hi Boris,
>>>
>>> I’ve found the
>>> documentations(https://github.com/torvalds/linux/blob/master/Documentation/ABI/testing/sysfs-hypervisor-pmu)
>>> in the kernel source code, and it seems like if we change the mode
>>> from *self* to *all* then we can collect counters for all the domains,
>>> right?
>>
>> Yes, this will allow the hypervisor to collect samples from multiple
>> guests. However, the tool (perf) probably won't be able to properly
>> process these samples. But you can try.
>>
>> You will want to run dom0 on all physical processors (i.e. no
>> dom0_max_vcpus boot option) and pin all VCPUs for both dom0 and the
>> guest.
>>
>>
>> -boris
>>
>>>
>>> All the best,
>>> Sanghyun.
>>>
>>>
 On Aug 29, 2016, at 12:36 PM, Boris Ostrovsky
 
 > wrote:

 On 08/29/2016 09:18 AM, Sanghyun Hong wrote:
> Dear Xen-Devel Community:
>
> I’m a grad student working on measuring performance counters at the
> Xen domains. I read this
> thread(https://wiki.xenproject.org/wiki/Xen_Profiling:_oprofile_and_perf)
> in
> web, and it says using Linux perf command will let us collecting
> performance counters in both dom0 and domU. Does it mean that we can
> collect both of them at once if we run perf command on the dom0? (If
> not, does it mean we can collect counters for each domain separately
> once we run the perf command in each domain?

 Profiling both guest and dom0 (and the hypervisor) requires changes to
 perf and those are not there yet.

 But you can run perf in each guest (including dom0) separately. Make
 sure you have vpmu=true boot option.

 -boris





>>>
>>
>>
>



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

Re: [Xen-devel] Questions about Using Perf at Dom0

On 08/29/2016 02:42 PM, Sanghyun Hong wrote:
> Hi Boris, 
>
> I’ve found the
> documentations(https://github.com/torvalds/linux/blob/master/Documentation/ABI/testing/sysfs-hypervisor-pmu)
> in the kernel source code, and it seems like if we change the mode
> from *self* to *all* then we can collect counters for all the domains,
> right?

Yes, this will allow the hypervisor to collect samples from multiple
guests. However, the tool (perf) probably won't be able to properly
process these samples. But you can try.

You will want to run dom0 on all physical processors (i.e. no
dom0_max_vcpus boot option) and pin all VCPUs for both dom0 and the guest.


-boris

>
> All the best,
> Sanghyun.
>
>
>> On Aug 29, 2016, at 12:36 PM, Boris Ostrovsky
>> > wrote:
>>
>> On 08/29/2016 09:18 AM, Sanghyun Hong wrote:
>>> Dear Xen-Devel Community:
>>>
>>> I’m a grad student working on measuring performance counters at the
>>> Xen domains. I read this
>>> thread(https://wiki.xenproject.org/wiki/Xen_Profiling:_oprofile_and_perf)
>>> in
>>> web, and it says using Linux perf command will let us collecting
>>> performance counters in both dom0 and domU. Does it mean that we can
>>> collect both of them at once if we run perf command on the dom0? (If
>>> not, does it mean we can collect counters for each domain separately
>>> once we run the perf command in each domain?
>>
>> Profiling both guest and dom0 (and the hypervisor) requires changes to
>> perf and those are not there yet.
>>
>> But you can run perf in each guest (including dom0) separately. Make
>> sure you have vpmu=true boot option.
>>
>> -boris
>>
>>
>>
>>
>>
>



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

Re: [Xen-devel] [PATCH v2 1/2] mini-os: partially revert "remove using start_info ..."

Juergen Gross, on Mon 29 Aug 2016 16:18:26 +0200, wrote:
> Commit e33452c4f5547ed14defe6382b3b53664ac5bd8a ("remove using
> start_info in architecture independent code") removed the start_info
> variable completely. grub stubdom needs the start_info structure.
> 
> Readd the start_info structure, but make it dependent on
> CONFIG_PARAVIRT.
> 
> Signed-off-by: Juergen Gross 

Reviewed-by: Samuel Thibault 

> ---
>  arch/x86/setup.c | 12 
>  include/hypervisor.h | 13 -
>  2 files changed, 24 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/setup.c b/arch/x86/setup.c
> index 86955cf..5278227 100644
> --- a/arch/x86/setup.c
> +++ b/arch/x86/setup.c
> @@ -33,6 +33,14 @@
>  #include 
>  #include 
>  
> +#ifdef CONFIG_PARAVIRT
> +/*
> + * This structure contains start-of-day info, such as pagetable base pointer,
> + * address of the shared_info structure, and things like that.
> + */
> +union start_info_union start_info_union;
> +#endif
> +
>  /*
>   * Shared page for communicating with the hypervisor.
>   * Events flags go here, for example.
> @@ -189,6 +197,10 @@ arch_init(void *par)
>   /* print out some useful information  */
>   print_start_of_day(par);
>  
> +#ifdef CONFIG_PARAVIRT
> + memcpy(_info, par, sizeof(start_info));
> +#endif
> +
>   start_kernel();
>  }
>  
> diff --git a/include/hypervisor.h b/include/hypervisor.h
> index 3073a8a..f3b1f3c 100644
> --- a/include/hypervisor.h
> +++ b/include/hypervisor.h
> @@ -27,7 +27,18 @@
>  #include 
>  
>  /* hypervisor.c */
> -#ifndef CONFIG_PARAVIRT
> +#ifdef CONFIG_PARAVIRT
> +/*
> + * a placeholder for the start of day information passed up from the 
> hypervisor
> + */
> +union start_info_union
> +{
> +start_info_t start_info;
> +char padding[512];
> +};
> +extern union start_info_union start_info_union;
> +#define start_info (start_info_union.start_info)
> +#else
>  int hvm_get_parameter(int idx, uint64_t *value);
>  int hvm_set_parameter(int idx, uint64_t value);
>  #endif
> -- 
> 2.6.6
> 

-- 
Samuel
 FYLG> Tiens, vlà une URL qui va bien :
 FYLG> ftp://127.0.0.1/WaReZ/NiouZeS/WinDoZe/NeWSMoNGeR/SuPeR
 c'est gentil sauf que l'adresse ne fonctionne pas sa me fais une erreur
 -+- Furtif in Guide du Neuneu Usenet :  -+-

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

Re: [Xen-devel] [PATCH v2 1/2] mini-os: partially revert "remove using start_info ..."

Samuel Thibault, on Mon 29 Aug 2016 22:49:07 +0200, wrote:
> Juergen Gross, on Mon 29 Aug 2016 16:18:26 +0200, wrote:
> > +union start_info_union
> > +{
> > +start_info_t start_info;
> > +char padding[512];
> > +};
> 
> Why defining a union? 512 is actually not enough for start_info_t.

Ah, sorry, that was already there :)

Samuel

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

Re: [Xen-devel] [PATCH v2 1/2] mini-os: partially revert "remove using start_info ..."

Hello,

Juergen Gross, on Mon 29 Aug 2016 16:18:26 +0200, wrote:
> +union start_info_union
> +{
> +start_info_t start_info;
> +char padding[512];
> +};

Why defining a union? 512 is actually not enough for start_info_t.

Samuel

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

Re: [Xen-devel] [PATCH 2/2] mini-os: don't get xenbus parameters if xenbus is disabled

Wei Liu, on Mon 29 Aug 2016 12:11:21 +0100, wrote:
> On Mon, Aug 29, 2016 at 01:01:09PM +0200, Juergen Gross wrote:
> > get_xenbus() should be called only if CONFIG_XENBUS is set.
> > 
> > Signed-off-by: Juergen Gross 
> 
> Reviewed-by: Wei Liu 

Acked-by: Samuel Thibault 

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

Re: [Xen-devel] [MINIOS PATCH 1/3] Makefile: simplify all_sources macro

Juergen Gross, on Mon 29 Aug 2016 15:07:20 +0200, wrote:
> On 29/08/16 15:01, Wei Liu wrote:
> > There is no SCCS file.
> > 
> > Signed-off-by: Wei Liu 
> 
> Reviewed-by: Juergen Gross 

Acked-by: Samuel Thibault 

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

Re: [Xen-devel] [MINIOS PATCH 3/3] gitignore: ignore files generated by various indexing software

Juergen Gross, on Mon 29 Aug 2016 15:07:55 +0200, wrote:
> On 29/08/16 15:01, Wei Liu wrote:
> > Signed-off-by: Wei Liu 
> 
> Reviewed-by: Juergen Gross 

Acked-by: Samuel Thibault 

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

Re: [Xen-devel] [MINIOS PATCH 2/3] Makefile: add gtags target

Juergen Gross, on Mon 29 Aug 2016 15:07:39 +0200, wrote:
> On 29/08/16 15:01, Wei Liu wrote:
> > Use GNU Global to generate source code index.
> > 
> > Signed-off-by: Wei Liu 
> 
> Reviewed-by: Juergen Gross 

Acked-by: Samuel Thibault 

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

[Xen-devel] Xen EFI build system and gcov

2016-08-29 Thread Wei Liu

Hi Jan

Today I had some free cycles so I spent some time looking at gcov
support in the hypervisor and tried to write a patch to fix the
currently broken gcov build. But my patch alone is not enough to fix
that.

There seems to be a problem with the EFI Makefile. With my patch
applied, efi/boot.init.o still gets all gcov options _and_
-DINIT_SECTIONS_ONLY. See output and patch for more context.

If I force efi to be disabled by putting in a hack into efi/Makefile,
Xen builds fine. It suggests for all other files my patch works.

I am confused why efi/boot.init.o gets both set of options and I'm not
sure what is the best approach to fix it.

Do you have any suggestion on fixing that?

Thanks
Wei.

gcc ... -fprofile-arcs -ftest-coverage -DTEST_COVERAGE -DINIT_SECTIONS_ONLY -c 
boot.c -o boot.o
objdump -h boot.o | sed -n '/[0-9]/{s,00*,0,g;p;}' | while read idx name sz 
rest; do \
case "$name" in \
.*.local) ;; \
.text|.text.*|.data|.data.*|.bss) \
test $sz != 0 || continue; \
echo "Error: size of boot.o:$name is 0x$sz" >&2; \
exit $(expr $idx + 1);; \
esac; \
done
Error: size of boot.o:.text is 0x012
/local/work/xen.git/xen/Rules.mk:184: recipe for target 'boot.init.o' failed

---8<---
From 36c9fe8274187c6f8a4caa6f6b9c354ca9db2866 Mon Sep 17 00:00:00 2001
From: Wei Liu 
Date: Mon, 29 Aug 2016 19:11:59 +0100
Subject: [PATCH] xen: fix gcov compilation

Currently enabling gcov in hypervisor won't build because although
26c9d03d ("gcov: Adding support for coverage information") claimed that
%.init.o files were excluded from applying compilation options, it was
in fact not true.

Fix that by filtering out the options correctly.

Signed-off-by: Wei Liu 
---
 xen/Rules.mk | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index a190ff0..e49566c 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -115,7 +115,9 @@ subdir-all := $(subdir-y) $(subdir-n)
 
 $(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y)): CFLAGS += 
-DINIT_SECTIONS_ONLY
 
-$(obj-$(coverage)): CFLAGS += -fprofile-arcs -ftest-coverage -DTEST_COVERAGE
+ifeq ($(coverage),y)
+$(filter-out %.init.o,$(obj-y) $(obj-bin-y) $(extra-y)): CFLAGS += 
-fprofile-arcs -ftest-coverage -DTEST_COVERAGE
+endif
 
 ifeq ($(lto),y)
 # Would like to handle all object files as bitcode, but objects made from
-- 
2.1.4


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

Re: [Xen-devel] [PATCH] xen: Remove event channel notification through Xen PCI platform device

On 08/26/2016 05:55 PM, KarimAllah Ahmed wrote:
> Ever since commit 254d1a3f02eb ("xen/pv-on-hvm kexec: shutdown watches
> from old kernel") using the INTx interrupt from Xen PCI platform device for
> event channel notification would just lockup the guest during bootup.
> postcore_initcall now calls xs_reset_watches which will eventually try to read
> a value from XenStore and will get stuck on read_reply at XenBus forever since
> the platform driver is not probed yet and its INTx interrupt handler is not
> registered yet. That means that the guest can not be notified at this moment 
> of
> any pending event channels and none of the per-event handlers will ever be
> invoked (including the XenStore one) and the reply will never be picked up by
> the kernel.
>
> The exact stack where things get stuck during xenbus_init:
>
> -xenbus_init
>  -xs_init
>   -xs_reset_watches
>-xenbus_scanf
> -xenbus_read
>  -xs_single
>   -xs_single
>-xs_talkv
>
> Vector callbacks have always been the favourite event notification mechanism
> since their introduction in commit 38e20b07efd5 ("x86/xen: event channels
> delivery on HVM.") and the vector callback feature has always been advertised
> for quite some time by Xen that's why INTx was broken for several years now
> without impacting anyone.
>
> Luckily this also means that event channel notification through INTx is
> basically dead-code which can be safely removed without impacting anybody 
> since
> it has been effectively disabled for more than 4 years with nobody complaining
> about it (at least as far as I'm aware of).
>
> This commit removes event channel notification through Xen PCI platform 
> device.
>
> Cc: Boris Ostrovsky 
> Cc: David Vrabel 
> Cc: Juergen Gross 
> Cc: Thomas Gleixner 
> Cc: Ingo Molnar 
> Cc: "H. Peter Anvin" 
> Cc: x...@kernel.org
> Cc: Konrad Rzeszutek Wilk 
> Cc: Bjorn Helgaas 
> Cc: Stefano Stabellini 
> Cc: Julien Grall 
> Cc: Vitaly Kuznetsov 
> Cc: Paul Gortmaker 
> Cc: Ross Lagerwall 
> Cc: xen-de...@lists.xenproject.org
> Cc: linux-ker...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Cc: Anthony Liguori 
> Signed-off-by: KarimAllah Ahmed 

Reviewed-by: Boris Ostrovsky 





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

Re: [Xen-devel] [PATCH RFC] tools/libxc, xen/x86: Added xc_set_mem_access_sparse()

2016-08-29 Thread Razvan Cojocaru

On 08/29/16 19:20, Jan Beulich wrote:
 On 29.08.16 at 18:02,  wrote:
>> On 08/29/16 18:42, Jan Beulich wrote:
>> On 29.08.16 at 17:29,  wrote:
 On 08/26/2016 11:14 AM, Jan Beulich wrote:
 On 26.08.16 at 09:40,  wrote:
>> On 08/26/16 10:18, Jan Beulich wrote:
>> On 26.08.16 at 08:11,  wrote:
 @@ -76,6 +76,17 @@ int mem_access_memop(unsigned long cmd,
  }
  break;
  
 +case XENMEM_access_op_set_access_sparse:
 +{
 +xen_pfn_t *arr = xmalloc_bytes(sizeof(xen_pfn_t) * mao.nr);
 +
 +// copy_from_guest(arr, mao.pfn_list, mao.nr);
>>>
>>> What is this (wrongly C++ style) comment about? I think this really
>>> wasn't meant to be a comment, so RFC or not - how do things work
>>> with this commented out? And where is the error checking for the
>>> allocation (which btw should be xmalloc_array(), but the need for
>>> an allocation here is questionable - the called function would better
>>> retrieve the GFNs one by one).
>>
>> They don't work, I forgot that comment in (the line should not have been
>> commented). I first wrote the patch on Xen 4.6 and there there was no
>> CHECK_mem_access_op, so I was just trying to figure out what went wrong
>> when I first saw the compile errors and tried this, then left it in
>> accidentally.
>>
>> Indeed, there should also be a check for allocation failure.
>>
>> Do you mean that I would do better to just copy_from_guest(,
>> mao.pfn_list + index, 1) in a for loop that sets mem_access restrictions?
>
> Yes, albeit it is copy_from_guest_offset(, mao.pfn_list, index, 1).

 Avoiding translation, to the best of my understanding (and tested with
 the latest version of the patch I'm working on) would then require
 replacing copy_from_guest() with copy_from_user(), which does not have a
 copy_from_user_offset() alternative.
>>>
>>> I don't follow - where did you see copy_from_user() used in such a
>>> case? If you go through the existing examples, you'll find that with
>>> some #define-s (re-vectoring to copy_from_compat_offset()) this
>>> can easily be taken care of.
>>
>> I was looking at xc_mem_paging_memop(), where the buffer parameter is
>> being sent via mpo.buffer, which is an uint64_aligned_t, which I thought
>> was what you meant. On the HV side, it's being copied_from_user().
>>
>> In the interest of preventing furher misunderstanding, could you please
>> point out a specific example you have in mind?
> 
> Actually, having looked again more closely, I'm not sure you need
> to use the compat version of the copying routine; you may need a
> thin handler in compat/memory.c. Before going to further search
> for a suitable example, would you mind pointing out what it is that
> does not work with copy_from_guest_offset()?

With this change:

@@ -452,6 +453,11 @@ struct xen_mem_access_op {
  * ~0ull is used to set and get the default access for pages
  */
 uint64_aligned_t pfn;
+/*
+ * List of pfns to set access for
+ * Used only with XENMEM_access_op_set_access_multi
+ */
+uint64_aligned_t pfn_list;
 };

combined with this change:

@@ -76,6 +76,17 @@ int mem_access_memop(unsigned long cmd,
 }
 break;

+case XENMEM_access_op_set_access_multi:
+{
+xen_pfn_t *arr = xmalloc_bytes(sizeof(xen_pfn_t) * mao.nr);
+
+copy_from_guest(arr, (void *)mao.pfn_list, mao.nr *
sizeof(xen_pfn_t));
+rc = p2m_set_mem_access(d, INVALID_GFN, arr, mao.nr, start_iter,
+MEMOP_CMD_MASK, mao.access, 0);
+xfree(arr);
+break;
+}

I get this compile-time error:

In file included from
/home/red/work/xen.git/xen/include/xen/guest_access.h:10:0,
 from mem_access.c:24:
mem_access.c: In function ‘mem_access_memop’:
/home/red/work/xen.git/xen/include/asm/guest_access.h:99:37: error:
request for member ‘p’ in something not a structure or union
 const typeof(*(ptr)) *_s = (hnd).p; \
 ^
/home/red/work/xen.git/xen/include/xen/guest_access.h:18:5: note: in
expansion of macro ‘copy_from_guest_offset’
 copy_from_guest_offset(ptr, hnd, 0, nr)
 ^
mem_access.c:83:9: note: in expansion of macro ‘copy_from_guest’
 copy_from_guest(arr, (void *)mao.pfn_list, mao.nr *
sizeof(xen_pfn_t));
 ^

In order for this to work, I need to either change from copy_to_guest()
to copy_from_user(), or change from uint64_aligned_t pfn_list; to
XEN_GUEST_HANDLE(xen_pfn_t) pfn_list;.


Thanks,
Razvan

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

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

2016-08-29 Thread osstest service owner

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  81caac0cd0f56b0052a7884e6bd99e3a652ddd59
baseline version:
 xen  8bc02b47e5833c374b35618729d147d2980d4e05

Last test of basis   100621  2016-08-25 13:04:15 Z4 days
Testing same since   100654  2016-08-29 15:01:51 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 
  Suravee Suthikulpanit 

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



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=81caac0cd0f56b0052a7884e6bd99e3a652ddd59
+ . ./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 
81caac0cd0f56b0052a7884e6bd99e3a652ddd59
+ branch=xen-unstable-smoke
+ revision=81caac0cd0f56b0052a7884e6bd99e3a652ddd59
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.7-testing
+ '[' x81caac0cd0f56b0052a7884e6bd99e3a652ddd59 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++

Re: [Xen-devel] Questions about Using Perf at Dom0