date:20161010

Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen

2016-10-10 Thread Haozhong Zhang

On 10/10/16 17:43, Andrew Cooper wrote:
> On 10/10/16 01:35, Haozhong Zhang wrote:
> > Overview
> > 
> > This RFC kernel patch series along with corresponding patch series of
> > Xen, QEMU and ndctl implements Xen vNVDIMM, which can map the host
> > NVDIMM devices to Xen HVM domU as vNVDIMM devices.
> >
> > Xen hypervisor does not include an NVDIMM driver, so it needs the
> > assistance from the driver in Dom0 Linux kernel to manage NVDIMM
> > devices. We currently only supports NVDIMM devices in pmem mode.
> >
> > Design and Implementation
> > =
> > The complete design can be found at
> >   
> > https://lists.xenproject.org/archives/html/xen-devel/2016-07/msg01921.html.
> >
> > All patch series can be found at
> >   Xen:  https://github.com/hzzhan9/xen.git nvdimm-rfc-v1
> >   QEMU: https://github.com/hzzhan9/qemu.git xen-nvdimm-rfc-v1
> >   Linux kernel: https://github.com/hzzhan9/nvdimm.git xen-nvdimm-rfc-v1
> >   ndctl:https://github.com/hzzhan9/ndctl.git pfn-xen-rfc-v1
> >
> > Xen hypervisor needs assistance from Dom0 Linux kernel for following tasks:
> > 1) Reserve an area on NVDIMM devices for Xen hypervisor to place
> >memory management data structures, i.e. frame table and M2P table.
> > 2) Report SPA ranges of NVDIMM devices and the reserved area to Xen
> >hypervisor.
> 
> Please can we take a step back here before diving down a rabbit hole.
> 
> 
> How do pblk/pmem regions appear in the E820 map at boot?  At the very
> least, I would expect at least a large reserved region.

ACPI specification does not require them to appear in E820, though
it defines E820 type-7 for persistent memory.

> 
> Is the MFN information (SPA in your terminology, so far as I can tell)
> available in any static APCI tables, or are they only available as a
> result of executing AML methods?
>

For NVDIMM devices already plugged at power on, their MFN information
can be got from NFIT table. However, MFN information for hotplugged
NVDIMM devices should be got via AML _FIT method, so point 2) is needed.

> 
> If the MFN information is only available via AML, then point 2) is
> needed, although the reporting back to Xen should be restricted to a xen
> component, rather than polluting the main device driver.
> 
> However, I can't see any justification for 1).  Dom0 should not be
> involved in Xen's management of its own frame table and m2p.  The mfns
> making up the pmem/pblk regions should be treated just like any other
> MMIO regions, and be handed wholesale to dom0 by default.
>

Do you mean to treat them as mmio pages of type p2m_mmio_direct and
map them to guest by map_mmio_regions()?

Thanks,
Haozhong

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

[Xen-devel] Xen 4.2.4 and 4.6 hangs

2016-10-10 Thread Soumendu Satapathy

Hi there,

I am trying to install and boot xen.  I followed the following procedure. There 
was no errors while installation. But when I select the grub entry it hangs.

The following is the steps I followed.

yum -y install centos-release-xen
yum --enablerepo=centos-virt-xen -y update kernel
yum --enablerepo=centos-virt-xen -y install xen
/bin/grub-bootxen.sh
reboot
xl info



I also tried to compile the xen4.2.4 source code . I did the following..

$ ./configure
$ make world
$ make install

After the above steps completed without errors, I added an entry to the 
grub.cfg and booted but like the above it hangs. But I am able to select the 
linux kernel and it boots properly. In both I get the following and then the 
xen hangs...

Loading Xen 4.6
Loading Linux 
Loading initial ramdisk ...



Is there any steps we are missing?


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

[Xen-devel] RXen 4.2.4 and 4.6 hangs

2016-10-10 Thread Soumendu Satapathy


Hi there,

Platform - Intel
CPU - Skylake

I am trying to install and boot xen.  I followed the following procedure. There 
was no errors while installation. But when I select the grub entry it hangs.

The following is the steps I followed.

yum -y install centos-release-xen
yum --enablerepo=centos-virt-xen -y update kernel
yum --enablerepo=centos-virt-xen -y install xen
/bin/grub-bootxen.sh
reboot
xl info


I also tried to compile the xen4.2.4 source code . I did the following..

$ ./configure
$ make world
$ make install

After the above steps completed without errors, I added an entry to the 
grub.cfg and booted but like the above it hangs. But I am able to select the 
linux kernel and it boots properly. In both I get the following and then the 
xen hangs...

Loading Xen 4.6
Loading Linux 
Loading initial ramdisk ...



Is there any steps we are missing?


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

Re: [Xen-devel] [PATCH v7] xen/sm{e, a}p: allow disabling sm{e, a}p for Xen itself

2016-10-10 Thread He Chen

On Mon, Oct 10, 2016 at 06:16:41AM -0600, Jan Beulich wrote:
> >>> On 09.10.16 at 10:20,  wrote:
> > Changes in v7:
> > * bugfix: fix the bug that this patch doesn't work on machine without SMAP.
> > * test: This patch has not been tested (on 32-bit PV environment).
> > Really sorry for that since I have took several days trying to
> > setup a 32-bit PV guest but finally failed.
> 
> Well, I don't know what to say. And since you don't say what your
> problem is/was, I also don't see how anyone could help.
> 
Apologies for sending out a patch without testing it entirely.
To be honest, I am not so fimilar with 32-bit PV guest...
I create a HVM guest and then compile linux kernel with the configuration
suggested by https://wiki.xen.org/wiki/Mainline_Linux_Kernel_Configs
after that, I copy vmlinuz and initramfs from guest to host and I boot
guest with PV cfg file below:
```
name="rhel32"
memory=2048
vcpus=2
on_crash="destroy"
on_poweroff="destroy"
on_reboot="restart"
localtime=0
builder="linux"
kernel="/root/xen_guest/rhel32pv/vmlinuz-4.8.0+"
ramdisk="/root/xen_guest/rhel32pv/initramfs-4.8.0+.img"
extra="root=/dev/xvda"
disk=['file:/root/xen_guest/rhel32pv/rhel32.img,xvda,w',]
vif=[ 'mac=00:15:3e:22:f5:1b','bridge=xenbr0']
```
The guest fail to boot and error message says can not find modules in
/lib/module...

I also try to install a PV guest directly by netboot way, but I am
blocked at "installing kernel" step, error shows and let me try.

The problems are trivial, and may I ask for some "how to build a 32-bit
PV guest on 64-bit host" reference wiki page or threads?

> > @@ -1404,12 +1448,16 @@ void __init noreturn __start_xen(unsigned long 
> > mbi_p)
> >  
> >  if ( !opt_smep )
> >  setup_clear_cpu_cap(X86_FEATURE_SMEP);
> > -if ( cpu_has_smep )
> > +else if ( cpu_has_smep && opt_smep == 1 )
> 
> How about
> 
> if ( cpu_has_smep && opt_smep != SMEP_HVM_ONLY )
> 
> (i.e. I dislike both the "else" and the hard-coded 1)? Or if you dislike
> this, then at least > 0 instead of == 1 please, or provide a #define
> just like you do for -1.

Sure, I would use `if ( cpu_has_smep && opt_smep != SMEP_HVM_ONLY )` in
next version.
BTW. In v6 patch, I missed `cpu_has_smep` and that's why this patch is
buggy on the machine without smap/smep hardware feature.

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

Re: [Xen-devel] [v2 1/3] x86: refactor psr implementation in hypervisor.

2016-10-10 Thread Yi Sun

On 16-10-10 01:34:47, Jan Beulich wrote:
> >>> On 09.10.16 at 08:43,  wrote:
> > On 16-09-30 17:18:33, Konrad Rzeszutek Wilk wrote:
> >> On Thu, Sep 22, 2016 at 10:15:20AM +0800, Yi Sun wrote:
> >> > Current psr.c is designed for supporting L3 CAT/CDP. It has many
> >> > limitations to add new feature. Considering to support more PSR
> >> > features, we need refactor PSR implementation to make it more
> >> > flexible and fulfill the principle, open for extension but closed
> >> > for modification.
> >> > 
> >> > The core of the refactoring is to abstract the common actions and
> >> > encapsulate them into "struct feat_ops". The detailed steps to add
> >> > a new feature are described at the head of psr.c.
> >> > 
> >> > Signed-off-by: Yi Sun 
> >> > 
> >> > ---
> >> > Changed since v1:
> >> >  * sysctl.c
> >> > - Interface change for abstraction requirement.
> >> >  * psr.c
> >> > - Function and variables names are changed to express accurately.
> >> > - Fix code style issues.
> >> > - Fix imprecise comments.
> >> > - Add one callback function, get_cos_num(), to fulfill the
> >> >   abstraction requirement.
> >> > - Divide get_old_set_new() callback functions into two functions:
> >> >   get_old_val() and set_new_val() make it more primitive.
> >> > - Change feat_info type from an array to union.
> >> > - Adjust some functions to replace if to switch to make them
> >> >   clearer.
> >> > - Replace custom list management to system.
> >> > - Use 'const' to make codes more safe.
> >> >  * psr.h
> >> > - Change 'enum mask_type' to 'enum psr_val_type' to express
> >> >   more accurate.
> >> > - Change parameters of psr_get_info() to fulfill abstraction
> >> >   requirement.
> >> > ---
> >> >  xen/arch/x86/domctl.c |   36 +-
> >> >  xen/arch/x86/psr.c| 1105 
> >> > +++--
> >> 
> >> Whoa. 1K changes. This is a dense patch.
> >> 
> > Yes, a little big because it refactors psr.c. :-)
> 
> Please nevertheless strive to break it up some, to aid reviewing. I
> have to admit that I'm on the edge of NAK-ing such a hard to review
> change to code that is of no core interest (at least as long as all of
> this remains Atom-only).
> 
Very sorry for this. I will try my best to split this big patch to
some small patches in V3.

> Also to both of you: Please limit the quoting in your replies.

Got it. Thank you for guidance!

> 
> Jan

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

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

2016-10-10 Thread osstest service owner

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101328
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101328
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 101328

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   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-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 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-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail 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-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 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-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
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-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass

version targeted for testing:
 qemuu0f183e679d85fec74fc83f35f973cf8e56d97861
baseline version:
 qemuu48f592118ab42f83a1a7561c4bfd2b72a100f241

Last test of basis   101328  2016-10-07 21:44:14 Z3 days
Failing since101353  2016-10-10 11:13:43 Z0 days2 attempts
Testing same since   101358  2016-10-10 17:46:58 Z0 days1 attempts


People who touched revisions under test:
  Alex BennÃ©e 
  Artyom Tarasenko 
  Chen Fan 
  Daniel P. Berrange 
  David Anderson 
  David Kiarie 
  Eduardo Habkost 
  Emilio G. Cota 
  Eric Blake 
  Fam Zheng 
  Felix Janda 
  Gerd Hoffmann 
  Greg Ungerer 
  HervÃ© Poussineau 
  Jonathan NeuschÃ¤fer 
  Junlian Bell 
  Kevin Wolf 
  Li Qiang 
  Lin Ma 
  Luiz Capitulino 
  Marc-AndrÃ© Lureau 
  Markus Armbruster 
  Max Reitz 
  Michael Tokarev 
  Michal Privoznik 
  Paolo Bonzini 
  Peter Maydell 
  Peter Xu 
  Stefan Hajnoczi 
  Thomas Huth 
  Thomas Huth 
  TomÃ¡Å¡ GolembiovskÃ½ 
  Wei Yang 
  Xiao Long Jiang

Re: [Xen-devel] Xen virtual IOMMU high level design doc

2016-10-10 Thread Lan Tianyu

On 2016年10月06日 02:36, Konrad Rzeszutek Wilk wrote:
>>> 3.3 Interrupt remapping
>>> > > Interrupts from virtual devices and physical devices will be delivered
>>> > > to vlapic from vIOAPIC and vMSI. It needs to add interrupt remapping
>>> > > hooks in the vmsi_deliver() and ioapic_deliver() to find target vlapic
>>> > > according interrupt remapping table. The following diagram shows the 
>>> > > logic.
>>> > > 
> Uh? Missing diagram?

Sorry. This is stale statement. The diagram was moved to 2.2 Interrupt
remapping overview.

> 
>>> 4.3 Q35 vs i440x
>>> > > VT-D is introduced since Q35 chipset. Previous concern was that IOMMU
> s/since/with/
>>> > > driver has assumption that VTD only exists on Q35 and newer chipset and
>>> > > we have to enable Q35 first.
>>> > > 
>>> > > Consulted with Linux/Windows IOMMU driver experts and get that these
>>> > > drivers doesn't have such assumption. So we may skip Q35 implementation
>>> > > and can emulate vIOMMU on I440x chipset. KVM already have vIOMMU support
>>> > > with virtual PCI device's DMA translation and interrupt remapping. We
>>> > > are using KVM to do experiment of adding vIOMMU on the I440x and test
>>> > > Linux/Windows guest. Will report back when have some results.
> Any results?

We have booted up Win8 guest with virtual VTD and emulated I440x
platform on Xen and guest uses virtual VTD to enable interrupt remapping
function.

-- 
Best regards
Tianyu Lan

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

Re: [Xen-devel] [Resend PATCH 1/2] Xen/Keyhandler: Make keyhandler always run in tasklet

2016-10-10 Thread Lan Tianyu

On 2016年10月10日 21:55, Konrad Rzeszutek Wilk wrote:
> On Sat, Oct 08, 2016 at 11:26:44AM +0800, Lan Tianyu wrote:
>> On 2016年10月06日 20:52, Jan Beulich wrote:
>> On 30.09.16 at 04:19,  wrote:
 @@ -87,10 +89,10 @@ void handle_keypress(unsigned char key, struct 
 cpu_user_regs *regs)
  if ( key >= ARRAY_SIZE(key_table) || !(h = _table[key])->fn )
  return;
  
 -if ( !in_irq() || h->irq_callback )
 +if ( h->irq_callback )
>>>
>>> Please make subject/description reflect this: You don't _always_
>>> force the use of the tasklet.
>>
>> Ok. I also find register_irq_keyhandler() isn't called anywhere in
>> current code and that means none uses irq_callback. Can we remove it?
> 
> But it is. See IRQ_KEYHANDLER

Oh. Yes. Thanks for your information.

-- 
Best regards
Tianyu Lan

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

[Xen-devel] [PATCH v5 4/7] VMX: Make sure PI is in proper state before install the hooks

2016-10-10 Thread Feng Wu

We may hit the last ASSERT() in vmx_vcpu_block in the current code,
since vmx_vcpu_block() may get called before vmx_pi_switch_to()
has been installed or executed. Here We use cmpxchg to update
the NDST field, this can make sure we only update the NDST when
vmx_pi_switch_to() has not been called. So the NDST is in a
proper state in vmx_vcpu_block().

Suggested-by: Jan Beulich 
Signed-off-by: Feng Wu 
---
v5:
- Use 0x as the invalid value for NDST field.

 xen/arch/x86/hvm/vmx/vmcs.c | 13 +
 xen/arch/x86/hvm/vmx/vmx.c  | 27 ++-
 2 files changed, 31 insertions(+), 9 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index 1bd875a..10976bd 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -956,16 +956,13 @@ void virtual_vmcs_vmwrite(const struct vcpu *v, u32 
vmcs_encoding, u64 val)
  */
 static void pi_desc_init(struct vcpu *v)
 {
-uint32_t dest;
-
 v->arch.hvm_vmx.pi_desc.nv = posted_intr_vector;
 
-dest = cpu_physical_id(v->processor);
-
-if ( x2apic_enabled )
-v->arch.hvm_vmx.pi_desc.ndst = dest;
-else
-v->arch.hvm_vmx.pi_desc.ndst = MASK_INSR(dest, PI_xAPIC_NDST_MASK);
+/*
+ * Mark NDST as invalid, then we can use this invalid value as a
+ * marker to whether update NDST or not in vmx_pi_hooks_assign().
+ */
+v->arch.hvm_vmx.pi_desc.ndst = 0x;
 }
 
 static int construct_vmcs(struct vcpu *v)
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index b8b152a..b14c84e 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -211,14 +211,39 @@ static void vmx_pi_do_resume(struct vcpu *v)
 /* This function is called when pcidevs_lock is held */
 void vmx_pi_hooks_assign(struct domain *d)
 {
+struct vcpu *v;
+
 if ( !iommu_intpost || !has_hvm_container_domain(d) )
 return;
 
 ASSERT(!d->arch.hvm_domain.vmx.vcpu_block);
 
-d->arch.hvm_domain.vmx.vcpu_block = vmx_vcpu_block;
+/*
+ * We carefully handle the timing here:
+ * - Install the context switch first
+ * - Then set the NDST field
+ * - Install the block and resume hooks in the end
+ *
+ * This can make sure the PI (especially the NDST feild) is
+ * in proper state when we call vmx_vcpu_block().
+ */
 d->arch.hvm_domain.vmx.pi_switch_from = vmx_pi_switch_from;
 d->arch.hvm_domain.vmx.pi_switch_to = vmx_pi_switch_to;
+
+for_each_vcpu ( d, v )
+{
+unsigned int dest = cpu_physical_id(v->processor);
+struct pi_desc *pi_desc = >arch.hvm_vmx.pi_desc;
+
+/*
+ * We don't need to update NDST if 'arch.hvm_domain.vmx.pi_switch_to'
+ * already gets called
+ */
+(void)cmpxchg(_desc->ndst, 0x,
+x2apic_enabled ? dest : MASK_INSR(dest, PI_xAPIC_NDST_MASK));
+}
+
+d->arch.hvm_domain.vmx.vcpu_block = vmx_vcpu_block;
 d->arch.hvm_domain.vmx.pi_do_resume = vmx_pi_do_resume;
 }
 
-- 
2.1.0


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

[Xen-devel] [PATCH v5 5/7] VT-d: No need to set irq affinity for posted format IRTE

2016-10-10 Thread Feng Wu

We don't set the affinity for posted format IRTE, since the
destination of these interrupts is vCPU and the vCPU affinity
is set during vCPU scheduling.

Signed-off-by: Feng Wu 
---
v5:
- Only suppress affinity related IRTE updates for PI

 xen/drivers/passthrough/vtd/intremap.c | 52 --
 1 file changed, 49 insertions(+), 3 deletions(-)

diff --git a/xen/drivers/passthrough/vtd/intremap.c 
b/xen/drivers/passthrough/vtd/intremap.c
index bfd468b..8dd0373 100644
--- a/xen/drivers/passthrough/vtd/intremap.c
+++ b/xen/drivers/passthrough/vtd/intremap.c
@@ -547,6 +547,49 @@ static int remap_entry_to_msi_msg(
 return 0;
 }
 
+static bool_t pi_can_suppress_irte_update(struct iremap_entry *new,
+const struct iremap_entry *old)
+{
+bool_t ret = 1;
+u16 fpd, sid, sq, svt;
+
+if ( !old->remap.p || !old->remap.im )
+return 0;
+
+fpd = new->post.fpd;
+sid = new->post.sid;
+sq = new->post.sq;
+svt = new->post.svt;
+
+*new = *old;
+
+if ( fpd != old->post.fpd )
+{
+new->post.fpd = fpd;
+ret = 0;
+}
+
+if ( sid != old->post.sid )
+{
+new->post.sid = sid;
+ret = 0;
+}
+
+if ( sq != old->post.sq )
+{
+new->post.sq = sq;
+ret = 0;
+}
+
+if ( svt != old->post.svt )
+{
+new->post.svt = svt;
+ret = 0;
+}
+
+return ret;
+}
+
 static int msi_msg_to_remap_entry(
 struct iommu *iommu, struct pci_dev *pdev,
 struct msi_desc *msi_desc, struct msi_msg *msg)
@@ -637,9 +680,12 @@ static int msi_msg_to_remap_entry(
 remap_rte->address_hi = 0;
 remap_rte->data = index - i;
 
-memcpy(iremap_entry, _ire, sizeof(struct iremap_entry));
-iommu_flush_cache_entry(iremap_entry, sizeof(struct iremap_entry));
-iommu_flush_iec_index(iommu, 0, index);
+if ( !pi_can_suppress_irte_update(_ire, iremap_entry) )
+{
+memcpy(iremap_entry, _ire, sizeof(struct iremap_entry));
+iommu_flush_cache_entry(iremap_entry, sizeof(struct iremap_entry));
+iommu_flush_iec_index(iommu, 0, index);
+}
 
 unmap_vtd_domain_page(iremap_entries);
 spin_unlock_irqrestore(_ctrl->iremap_lock, flags);
-- 
2.1.0


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

[Xen-devel] [PATCH v5 3/7] VMX: Cleanup PI per-cpu blocking list when vcpu is destroyed

2016-10-10 Thread Feng Wu

We should remove the vCPU from the per-cpu blocking list
if it is going to be destroyed.

Signed-off-by: Feng Wu 
---
v5:
- Use vmx_pi_list_remove() instead of vmx_pi_list_cleanup()

 xen/arch/x86/hvm/vmx/vmx.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index d210516..b8b152a 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -337,6 +337,7 @@ static void vmx_vcpu_destroy(struct vcpu *v)
  * separately here.
  */
 vmx_vcpu_disable_pml(v);
+vmx_pi_list_remove(v);
 vmx_destroy_vmcs(v);
 vpmu_destroy(v);
 passive_domain_destroy(v);
-- 
2.1.0


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

[Xen-devel] [PATCH v5 2/7] VMX: Properly handle pi when all the assigned devices are removed

2016-10-10 Thread Feng Wu

This patch handles some concern cases when the last assigned device
is removed from the domain. In this case we should carefully handle
pi descriptor and the per-cpu blocking list, to make sure:
- all the PI descriptor are in the right state when next time a
devices is assigned to the domain again.
- No remaining vcpus of the domain in the per-cpu blocking list.

Here we call vmx_pi_list_remove() to remove the vCPU from the blocking list
if it is on the list. However, this could happen when vmx_vcpu_block() is
being called, hence we might incorrectly add the vCPU to the blocking list
while the last devcie is detached from the domain. Consider that the situation
can only occur when detaching the last device from the domain and it is not
a frequent operation, so we use domain_pause before that, which is considered
as an clean and maintainable solution for the situation.

Signed-off-by: Feng Wu 
---
v5:
- Remove a no-op wrapper

 xen/arch/x86/hvm/vmx/vmx.c | 28 
 1 file changed, 24 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 623d5bc..d210516 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -163,14 +163,12 @@ static void vmx_pi_switch_to(struct vcpu *v)
 pi_clear_sn(pi_desc);
 }
 
-static void vmx_pi_do_resume(struct vcpu *v)
+static void vmx_pi_list_remove(struct vcpu *v)
 {
 unsigned long flags;
 spinlock_t *pi_blocking_list_lock;
 struct pi_desc *pi_desc = >arch.hvm_vmx.pi_desc;
 
-ASSERT(!test_bit(_VPF_blocked, >pause_flags));
-
 /*
  * Set 'NV' field back to posted_intr_vector, so the
  * Posted-Interrupts can be delivered to the vCPU when
@@ -178,12 +176,12 @@ static void vmx_pi_do_resume(struct vcpu *v)
  */
 write_atomic(_desc->nv, posted_intr_vector);
 
-/* The vCPU is not on any blocking list. */
 pi_blocking_list_lock = v->arch.hvm_vmx.pi_blocking.lock;
 
 /* Prevent the compiler from eliminating the local variable.*/
 smp_rmb();
 
+/* The vCPU is not on any blocking list. */
 if ( pi_blocking_list_lock == NULL )
 return;
 
@@ -203,6 +201,13 @@ static void vmx_pi_do_resume(struct vcpu *v)
 spin_unlock_irqrestore(pi_blocking_list_lock, flags);
 }
 
+static void vmx_pi_do_resume(struct vcpu *v)
+{
+ASSERT(!test_bit(_VPF_blocked, >pause_flags));
+
+vmx_pi_list_remove(v);
+}
+
 /* This function is called when pcidevs_lock is held */
 void vmx_pi_hooks_assign(struct domain *d)
 {
@@ -220,14 +225,29 @@ void vmx_pi_hooks_assign(struct domain *d)
 /* This function is called when pcidevs_lock is held */
 void vmx_pi_hooks_deassign(struct domain *d)
 {
+struct vcpu *v;
+
 if ( !iommu_intpost || !has_hvm_container_domain(d) )
 return;
 
 ASSERT(d->arch.hvm_domain.vmx.vcpu_block);
 
+/*
+ * Pausing the domain can make sure the vCPU is not
+ * running and hence calling the hooks simultaneously
+ * when deassigning the PI hooks and removing the vCPU
+ * from the blocking list.
+ */
+domain_pause(d);
+
 d->arch.hvm_domain.vmx.vcpu_block = NULL;
 d->arch.hvm_domain.vmx.pi_do_resume = NULL;
 d->arch.hvm_domain.vmx.pi_switch_from = NULL;
+
+for_each_vcpu ( d, v )
+vmx_pi_list_remove(v);
+
+domain_unpause(d);
 }
 
 static int vmx_domain_initialise(struct domain *d)
-- 
2.1.0


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

[Xen-devel] [PATCH v5 6/7] VT-d: Some cleanups

2016-10-10 Thread Feng Wu

Use type-safe structure assignment instead of memcpy()
Use sizeof(*iremap_entry)

Signed-off-by: Feng Wu 
---
 xen/drivers/passthrough/vtd/intremap.c | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/xen/drivers/passthrough/vtd/intremap.c 
b/xen/drivers/passthrough/vtd/intremap.c
index 8dd0373..b6f8d3d 100644
--- a/xen/drivers/passthrough/vtd/intremap.c
+++ b/xen/drivers/passthrough/vtd/intremap.c
@@ -183,8 +183,8 @@ static void free_remap_entry(struct iommu *iommu, int index)
 GET_IREMAP_ENTRY(ir_ctrl->iremap_maddr, index,
  iremap_entries, iremap_entry);
 
-memset(iremap_entry, 0, sizeof(struct iremap_entry));
-iommu_flush_cache_entry(iremap_entry, sizeof(struct iremap_entry));
+memset(iremap_entry, 0, sizeof(*iremap_entry));
+iommu_flush_cache_entry(iremap_entry, sizeof(*iremap_entry));
 iommu_flush_iec_index(iommu, 0, index);
 
 unmap_vtd_domain_page(iremap_entries);
@@ -310,7 +310,7 @@ static int ioapic_rte_to_remap_entry(struct iommu *iommu,
 GET_IREMAP_ENTRY(ir_ctrl->iremap_maddr, index,
  iremap_entries, iremap_entry);
 
-memcpy(_ire, iremap_entry, sizeof(struct iremap_entry));
+new_ire = *iremap_entry;
 
 if ( rte_upper )
 {
@@ -353,8 +353,8 @@ static int ioapic_rte_to_remap_entry(struct iommu *iommu,
 remap_rte->format = 1;/* indicate remap format */
 }
 
-memcpy(iremap_entry, _ire, sizeof(struct iremap_entry));
-iommu_flush_cache_entry(iremap_entry, sizeof(struct iremap_entry));
+*iremap_entry = new_ire;
+iommu_flush_cache_entry(iremap_entry, sizeof(*iremap_entry));
 iommu_flush_iec_index(iommu, 0, index);
 
 unmap_vtd_domain_page(iremap_entries);
@@ -638,7 +638,8 @@ static int msi_msg_to_remap_entry(
 GET_IREMAP_ENTRY(ir_ctrl->iremap_maddr, index,
  iremap_entries, iremap_entry);
 
-memcpy(_ire, iremap_entry, sizeof(struct iremap_entry));
+if ( iremap_entry->remap.p )
+new_ire.remap.im = iremap_entry->remap.im;
 
 /* Set interrupt remapping table entry */
 new_ire.remap.fpd = 0;
@@ -682,8 +683,8 @@ static int msi_msg_to_remap_entry(
 
 if ( !pi_can_suppress_irte_update(_ire, iremap_entry) )
 {
-memcpy(iremap_entry, _ire, sizeof(struct iremap_entry));
-iommu_flush_cache_entry(iremap_entry, sizeof(struct iremap_entry));
+*iremap_entry = new_ire;
+iommu_flush_cache_entry(iremap_entry, sizeof(*iremap_entry));
 iommu_flush_iec_index(iommu, 0, index);
 }
 
-- 
2.1.0


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

[Xen-devel] [PATCH v5 0/7] VMX: Properly handle pi descriptor and per-cpu blocking list

2016-10-10 Thread Feng Wu

The current VT-d PI related code may operate incorrectly in the
following scenarios:
1. When the last assigned device is dettached from the domain, all
the PI related hooks are removed then, however, the vCPU can be
blocked, switched to another pCPU, etc, all without the aware of
PI. After the next time we attach another device to the domain,
which makes the PI realted hooks avaliable again, the status
of the pi descriptor is not true. Beside that, the blocking vcpu
may still remain in the per-cpu blocking in this case. Patch [1/6]
and [2/6] handle this.

2. After the domain is destroyed, the the blocking vcpu may also
remain in the per-cpu blocking. Handled in patch [3/6].

3. When IRTE is in posted mode, we don't need to set the irq
affinity for it, since the destination of these interrupts is
vCPU and the vCPU affinity is set during vCPU scheduling. Patch
[5/6] handles this.

4. When a pCPU is unplugged, and there might be vCPUs on its
list. Since the pCPU is offline, those vCPUs might not be woken
up again. [6/6] addresses it.

Feng Wu (7):
  VMX: Statically assign two PI hooks
  VMX: Properly handle pi when all the assigned devices are removed
  VMX: Cleanup PI per-cpu blocking list when vcpu is destroyed
  VMX: Make sure PI is in proper state before install the hooks
  VT-d: No need to set irq affinity for posted format IRTE
  VT-d: Some cleanups
  VMX: Fixup PI descriptor when cpu is offline

 xen/arch/x86/hvm/vmx/vmcs.c|  14 ++---
 xen/arch/x86/hvm/vmx/vmx.c | 112 ++---
 xen/drivers/passthrough/vtd/intremap.c |  65 ---
 xen/include/asm-x86/hvm/vmx/vmx.h  |   1 +
 4 files changed, 168 insertions(+), 24 deletions(-)

-- 
2.1.0


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

[Xen-devel] [PATCH v5 7/7] VMX: Fixup PI descriptor when cpu is offline

2016-10-10 Thread Feng Wu

When cpu is offline, we need to move all the vcpus in its blocking
list to another online cpu, this patch handles it.

Signed-off-by: Feng Wu 
---
v5:
- Add some comments to explain why it doesn't cause deadlock
for the ABBA deadlock scenario.

 xen/arch/x86/hvm/vmx/vmcs.c   |  1 +
 xen/arch/x86/hvm/vmx/vmx.c| 48 +++
 xen/include/asm-x86/hvm/vmx/vmx.h |  1 +
 3 files changed, 50 insertions(+)

diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index 10976bd..5dd68ca 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -578,6 +578,7 @@ void vmx_cpu_dead(unsigned int cpu)
 vmx_free_vmcs(per_cpu(vmxon_region, cpu));
 per_cpu(vmxon_region, cpu) = 0;
 nvmx_cpu_dead(cpu);
+vmx_pi_desc_fixup(cpu);
 }
 
 int vmx_cpu_up(void)
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index b14c84e..c71d496 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -208,6 +208,54 @@ static void vmx_pi_do_resume(struct vcpu *v)
 vmx_pi_list_remove(v);
 }
 
+void vmx_pi_desc_fixup(int cpu)
+{
+unsigned int new_cpu, dest;
+unsigned long flags;
+struct arch_vmx_struct *vmx, *tmp;
+spinlock_t *new_lock, *old_lock = _cpu(vmx_pi_blocking, cpu).lock;
+struct list_head *blocked_vcpus = _cpu(vmx_pi_blocking, cpu).list;
+
+if ( !iommu_intpost )
+return;
+
+/*
+ * We are in the context of CPU_DEAD or CPU_UP_CANCELED notification,
+ * and it is impossible for a second CPU go down in parallel. So we
+ * can safely acquire the old cpu's lock and then acquire the new_cpu's
+ * lock after that.
+ */
+spin_lock_irqsave(old_lock, flags);
+
+list_for_each_entry_safe(vmx, tmp, blocked_vcpus, pi_blocking.list)
+{
+/*
+ * We need to find an online cpu as the NDST of the PI descriptor, it
+ * doesn't matter whether it is within the cpupool of the domain or
+ * not. As long as it is online, the vCPU will be woken up once the
+ * notification event arrives.
+ */
+new_cpu = cpumask_any(_online_map);
+new_lock = _cpu(vmx_pi_blocking, new_cpu).lock;
+
+spin_lock(new_lock);
+
+ASSERT(vmx->pi_blocking.lock == old_lock);
+
+dest = cpu_physical_id(new_cpu);
+write_atomic(>pi_desc.ndst,
+ x2apic_enabled ? dest : MASK_INSR(dest, 
PI_xAPIC_NDST_MASK));
+
+list_move(>pi_blocking.list,
+  _cpu(vmx_pi_blocking, new_cpu).list);
+vmx->pi_blocking.lock = new_lock;
+
+spin_unlock(new_lock);
+}
+
+spin_unlock_irqrestore(old_lock, flags);
+}
+
 /* This function is called when pcidevs_lock is held */
 void vmx_pi_hooks_assign(struct domain *d)
 {
diff --git a/xen/include/asm-x86/hvm/vmx/vmx.h 
b/xen/include/asm-x86/hvm/vmx/vmx.h
index 4cdd9b1..9783c70 100644
--- a/xen/include/asm-x86/hvm/vmx/vmx.h
+++ b/xen/include/asm-x86/hvm/vmx/vmx.h
@@ -569,6 +569,7 @@ void free_p2m_hap_data(struct p2m_domain *p2m);
 void p2m_init_hap_data(struct p2m_domain *p2m);
 
 void vmx_pi_per_cpu_init(unsigned int cpu);
+void vmx_pi_desc_fixup(int cpu);
 
 void vmx_pi_hooks_assign(struct domain *d);
 void vmx_pi_hooks_deassign(struct domain *d);
-- 
2.1.0


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

[Xen-devel] [PATCH v5 1/7] VMX: Statically assign two PI hooks

2016-10-10 Thread Feng Wu

PI hooks: vmx_pi_switch_from() and vmx_pi_switch_to() are
needed even when any previously assigned device is detached
from the domain. Since 'SN' bit is also used to control the
CPU side PI and we change the state of SN bit in these two
functions, then evaluate this bit in vmx_deliver_posted_intr()
when trying to deliver the interrupt in posted way via software.
The problem is if we deassign the hooks while the vCPU is runnable
in the runqueue with 'SN' set, all the furture notificaton event
will be suppressed. This patch makes these two hooks statically
assigned.

Signed-off-by: Feng Wu 
---
v5:
- Zap "pi_switch_from" hook

 xen/arch/x86/hvm/vmx/vmx.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 3d330b6..623d5bc 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -147,6 +147,11 @@ static void vmx_pi_switch_from(struct vcpu *v)
 pi_set_sn(pi_desc);
 }
 
+/*
+ * In fact, we can remove this hooks inside itself if no new device is in the
+ * process of getting assigned and "from" hook is NULL. However, it is not
+ * straightforward to find a clear solution, so just leave it here.
+ */
 static void vmx_pi_switch_to(struct vcpu *v)
 {
 struct pi_desc *pi_desc = >arch.hvm_vmx.pi_desc;
@@ -221,9 +226,8 @@ void vmx_pi_hooks_deassign(struct domain *d)
 ASSERT(d->arch.hvm_domain.vmx.vcpu_block);
 
 d->arch.hvm_domain.vmx.vcpu_block = NULL;
-d->arch.hvm_domain.vmx.pi_switch_from = NULL;
-d->arch.hvm_domain.vmx.pi_switch_to = NULL;
 d->arch.hvm_domain.vmx.pi_do_resume = NULL;
+d->arch.hvm_domain.vmx.pi_switch_from = NULL;
 }
 
 static int vmx_domain_initialise(struct domain *d)
-- 
2.1.0


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

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

2016-10-10 Thread osstest service owner

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-raw  6 xen-boot fail REGR. vs. 101347

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

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

version targeted for testing:
 xen  78ff18c905318a9b1e5dd32662986f03b10a4e56
baseline version:
 xen  84c1e7d8017c773c41d6e8b79384f37a67be1479

Last test of basis   101347  2016-10-10 02:00:16 Z0 days
Testing same since   101355  2016-10-10 13:44:07 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64-xtf  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
 build-amd64-prev pass

Re: [Xen-devel] [PATCH v4 5/6] VT-d: No need to set irq affinity for posted format IRTE

2016-10-10 Thread Wu, Feng

> >> How do you know? Judging just from current callers is - as said
> >> before - calling for trouble down the road. And the function clearly
> >> creates a brand new IRTE, which fully replaces the previous one.
> >
> > This function copy the old IRTE to 'new_ire' and it doesn't touch
> > fields like 'sid', 'sq', and 'svt', so how could these bits get changed?
> 
> The function calls set_msi_source_id(), doesn't it? 

Oh, yes, it does! Sorry for the negligence.

Thanks,
Feng

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

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

2016-10-10 Thread osstest service owner

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

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  68dc7185cbffab34211c77339874f2ea517990fd
baseline version:
 xen  0a9d8a57e1f9024459e613e831905d28ef72051a

Last test of basis   101356  2016-10-10 14:02:50 Z0 days
Testing same since   101359  2016-10-10 19:02:20 Z0 days1 attempts


People who touched revisions under test:
  Konrad Rzeszutek Wilk 
  Stefano Stabellini 

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=68dc7185cbffab34211c77339874f2ea517990fd
+ . ./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 
68dc7185cbffab34211c77339874f2ea517990fd
+ branch=xen-unstable-smoke
+ revision=68dc7185cbffab34211c77339874f2ea517990fd
+ . ./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
+ '[' x68dc7185cbffab34211c77339874f2ea517990fd = 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
++ :

[Xen-devel] `xl create` hang on skylake desktop

2016-10-10 Thread Lai, Paul

Hi Shannon:

I’m reporting that commit 38cd0664a6bf1c3b887992ea029d2bb516f52c59 is causing a
hang in the `xl create windows7` command on my skylake desktop.  This is a
regression from previous behavior.

commit 38cd0664a6bf1c3b887992ea029d2bb516f52c59
Author: Shannon Zhao 
Date:   Wed Sep 28 18:19:02 2016 -0700

libxl/arm: Add the size of ACPI tables to maxmem

Here it adds the ACPI tables size to set the target maxmem to avoid
providing less available memory for guest.

Signed-off-by: Shannon Zhao 
Acked-by: Wei Liu 

I’ve was able to chase down this patchset by bisecting between
40277cded320efa32b86c0c9f01e33145eab5ee4 and
343f84be135e6f9e681960a9e235296eae159fc8.
I’ve confirmed that reverting 38cd0664a6bf1c3b887992ea029d2bb516f52c59 cleanly
avoids the hang.

I'm wondering how best to go forward,

Regards,
-Paul

PS:
Other info that might be helpful.

My CPU is:
processor   : 7
vendor_id   : GenuineIntel
cpu family  : 6
model   : 94
model name  : Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz

The contents of the simple windows7 config file are:
name="windows7"
description="None"
uuid="5c12c654-5ef4-d447-73de-ae106605f519"
memory=1024
maxmem=1024
vcpus=2
on_poweroff="destroy"
on_reboot="restart"
on_crash="destroy"
localtime=1
keymap="en-us"

builder="hvm"
boot="c"
disk=[ 
'/rhel-home/pclai/xen-images/p2m_test/ia32_win7_ent.img,raw,hda,w', ]
vif=[ 'mac=00:16:3e:4b:66:5f,bridge=br0,model=rtl8139', ]



stdvga=0
vnc=1
vncunused=1
soundhw="sb16"

viridian=0
usb=1
acpi=1
pae=1

usbdevice='tablet'

serial="pty"

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

Re: [Xen-devel] [driver question] IOMMU concept in Xen

2016-10-10 Thread Maciek


Yes you are right,

I was too focused on my issue that I didn't specify what I am trying to 
achieve :)
My company current driver can work as normal PF pci device, and also we 
support SR-IOV.
In driver initialization we can call sriov_configure to turn on SRIOV 
and enable VFs.
To be able to run on VM using VF we need IOMMU enabled (currently we 
recommend our

customers to add parameter to kernel intel_iommu=on).
But because we have many cases when people were trying to run driver 
without iommu,
caused fail, that VFs were visible but driver not working we decided to 
handle inside sriov_configure

call to handle this case by using simple check by iommu_present.
That solve our issue till we moved to Xen.
As I pointed out on Xen we didn't see iommu on Dom0, and that cause our 
check to don't enable sriov.
After we removed this check driver works perfectly fine, but we are in 
the same place.
So my intention is to leave this check in case of other hypervisor, and 
also meet Xen requirements about iommu handling.


Is that put more sense on my investigation?

Thanks
Maciej


On 10/10/16 00:44, Jan Beulich wrote:

On 10.10.16 at 02:19,  wrote:

During development of linux kernel PCI driver with SR-IOV I meet some
difficulty and I wanted to make sure that I understand correctly Xen
concepts.

Things that confuse me is build in function: iommu_present. Is usually
used in driver that are using iommu to work.
My problem is that this function work perfectly fine on bare-metal
linux, but when I move to Xen (or XenServer) then this function return
always false.

I know that Xen concept move IOMMU from linux kernel (which is on xen
just VM) to the hyperviosr. In XenServer is done using command:
xen-cmdline --set-xen iommu=1. After this command (and restart) iommu
should work.
I can also add this parameter to kernel cmd line (intel_iommu=on). Using
that in kernel messages I can see message: Intel-IOMMU: enabled. But no
matter which way I follow, iommu_present will always return me false.

I just commented out this check block and run whole driver, there wasn't
any issue and driver works perfectly.

After that I if there are other drivers in kernel that have the same
issue, but I didn't find anything that can solve this issue. One driver
check has conditional compilation for iommu_present block: #if
IS_ENABLED(CONFIG_IOMMU_API), but in XenServer (I checked XS 6.5) this
option is set to yes in kernel configuration. (This driver source is:
drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c)

Using grep I found other drivers that can run into same trouble (doesn't
start or throw warning log) inside Xen as dom0:
## drivers that are uisng iommu_present
drivers/gpu/drm/tegra/drm.c
drivers/infiniband/hw/usnic/usnic_uiom.c
drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
drivers/vfio/vfio.c
drivers/gpu/drm/msm/msm_gem.c
drivers/gpu/drm/msm/msm_drv.c
drivers/gpu/drm/mediatek/mtk_drm_drv.c
drivers/crypto/qat/qat_common/adf_sriov.c

So there are two options: there drivers are not designed for Xen or I
totally mess up something.

In my driver I started thinking to use #if IS_ENABLED(CONFIG_XEN_DOM0)
to handle different Hypervisor, but maybe is not right solution.

What you don't clarify in all of the above explanations and analysis
is - why do you need to know in the driver in the first place. To a
guest the presence of an IOMMU should be transparent. There may
be certain cases where Dom0 drivers need to know, but such then
need to be made interact with Xen (as the entity driving the IOMMU),
i.e. can't normally work on Xen without some minimal adjustments.
And this should really be the exception, not the rule.

Jan




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

[Xen-devel] [PATCH] Don't clear HCR_VM bit when updating VTTBR.

2016-10-10 Thread Jun Sun

Currently function p2m_restore_state() would clear HCR_VM bit, i.e.,
disabling stage2 translation, before updating VTTBR register. After
some research and talking to ARM support, I got confirmed that this is not
necessary. We are currently working on a new platform that would need this
to be removed.

The patch is tested on FVP foundation model.

Signed-off-by: Jun Sun 
---
 xen/arch/arm/p2m.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index cc5634b..e4991df 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -140,8 +140,6 @@ void p2m_restore_state(struct vcpu *n)
 return;
 
 hcr = READ_SYSREG(HCR_EL2);
-WRITE_SYSREG(hcr & ~HCR_VM, HCR_EL2);
-isb();
 
 WRITE_SYSREG64(p2m->vttbr, VTTBR_EL2);
 isb();
-- 
2.7.4


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

Re: [Xen-devel] [RFC QEMU PATCH 8/8] qmp: add a qmp command 'query-nvdimms' to get plugged NVDIMM devices

2016-10-10 Thread Eric Blake

On 10/09/2016 07:34 PM, Haozhong Zhang wrote:
> Xen uses this command to get the backend resource, guest SPA and size of
> NVDIMM devices so as to map them to guest.
> 
> Signed-off-by: Haozhong Zhang 
> ---
> Cc: Markus Armbruster 

> +++ b/docs/qmp-commands.txt
> @@ -3800,3 +3800,39 @@ Example for pc machine type started with
>  "props": {"core-id": 0, "socket-id": 0, "thread-id": 0}
>   }
> ]}
> +
> +EQMP
> +
> +{
> +.name   = "query-nvdimms",
> +.args_type  = "",
> +.mhandler.cmd_new = qmp_marshal_query_nvdimms,

Needs rebasing - we no longer need SQMP/EQMP sections or callouts to the
initializers, now that commit bd6092e4 has automated the mapping of QAPI
to command registration.

> +},
> +
> +SQMP
> +Show plugged NVDIMM devices
> +---
> +
> +Arguments: None.
> +
> +Example for pc machine type started with
> +-object memory-backend-file,id=mem1,mem-path=/path/to/nvm1,size=4G
> +-device nvdimm,id=nvdimm1,memdev=mem1
> +-object memory-backend-file,id=mem2,mem-path=/path/to/nvm2,size=8G
> +-device nvdimm,id=nvdimm2,memdev=mem2:
> +
> +-> { "execute": "query-nvdimms" }
> +<- { "returns": [
> +  {
> + "mem-path": "/path/to/nvm1",
> +  "slot": 0,

TAB damage; please fix.

> +  "spa": 17179869184,
> +  "length": 4294967296
> +  },
> +  {
> + "mem-path": "/path/to/nvm2",
> +  "slot": 1,
> +  "spa": 21474836480,
> +  "length": 8589934592
> +  }
> +   ]}

> +++ b/qapi-schema.json
> @@ -4646,3 +4646,32 @@
>  # Since: 2.7
>  ##
>  { 'command': 'query-hotpluggable-cpus', 'returns': ['HotpluggableCPU'] }
> +
> +##
> +# @NvdimmInfo
> +#
> +# Information about an NVDIMM device.
> +#
> +# @mem-path: the backend file of the NVDIMM device
> +#
> +# @slot: the slot index of the NVDIMM device
> +#
> +# @spa: the 64-bit SPA base address of the NVDIMM device
> +#
> +# @length: the 64-bit size in bytes of the NVDIMM device
> +#
> +# Since 2.8
> +##
> +{ 'struct': 'NvdimmInfo',
> +  'data': {'mem-path' : 'str', 'slot': 'int', 'spa': 'int', 'length': 'int'} 
> }
> +
> +##
> +# @query-nvdimms:
> +#
> +# Returns information about each NVDIMM device
> +#
> +# Returns: a list of @NvdimmInfo for each device
> +#
> +# Since: 2.8
> +##
> +{ 'command': 'query-nvdimms', 'returns': ['NvdimmInfo'] }
> 

Is this something that can be added to the existing query-memdev or
query-memory-devices command, instead of needing a new command?

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



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] fix EFI part of "symbols: Generate an xen-sym.map"

2016-10-10 Thread Stefano Stabellini

On Mon, 10 Oct 2016, Konrad Rzeszutek Wilk wrote:
> On Mon, Oct 10, 2016 at 01:28:16AM -0600, Jan Beulich wrote:
> > >>> On 07.10.16 at 19:57,  wrote:
> > > On Wed, 21 Sep 2016, Konrad Rzeszutek Wilk wrote:
> > >> On Wed, Sep 21, 2016 at 10:04:21AM -0600, Jan Beulich wrote:
> > >> > >>> On 21.09.16 at 17:59,  wrote:
> > >> > > The fix can be done two ways:
> > >> > >  a) See if xen.efi.map exists and then copy it
> > >> > >  b) Or link xen.efi.map to xen-syms.map (similar to how xen.efi is 
> > >> > > linked
> > >> > > against xen).
> > >> > > 
> > >> > > The patch chooses the latter.
> > >> > 
> > >> > Well, if the ARM maintainers like that ... I don't really see a point 
> > >> > in
> > >> > installing the same file twice without its second incarnation having a
> > >> > specific purpose.
> > >> 
> > >> I also have the a) part ready, which is simple:
> > >> 
> > >> 
> > >> diff --git a/xen/Makefile b/xen/Makefile
> > >> index e989a20..678f188 100644
> > >> --- a/xen/Makefile
> > >> +++ b/xen/Makefile
> > >> @@ -67,7 +67,9 @@ _install: $(TARGET)$(CONFIG_XEN_INSTALL_SUFFIX)
> > >>  if [ -r $(TARGET).efi -a -n '$(EFI_DIR)' ]; then \
> > >>  [ -d $(D)$(EFI_DIR) ] || $(INSTALL_DIR) $(D)$(EFI_DIR); 
> > >> \
> > >>  $(INSTALL_DATA) $(TARGET).efi 
> > >> $(D)$(EFI_DIR)/$(T)-$(XEN_FULLVERSION).efi; \
> > >> -$(INSTALL_DATA) $(TARGET).efi.map 
> > >> $(D)$(DEBUG_DIR)/$(T)-$(XEN_FULLVERSION).efi.map; \
> > >> +if [ -e $(TARGET).efi.map ]; then \
> > >> +$(INSTALL_DATA) $(TARGET).efi.map 
> > >> $(D)$(DEBUG_DIR)/$(T)-$(XEN_FULLVERSION).efi.map; \
> > >> +fi; \
> > >>  ln -sf $(T)-$(XEN_FULLVERSION).efi 
> > >> $(D)$(EFI_DIR)/$(T)-$(XEN_VERSION).$(XEN_SUBVERSION).efi; \
> > >>  ln -sf $(T)-$(XEN_FULLVERSION).efi 
> > >> $(D)$(EFI_DIR)/$(T)-$(XEN_VERSION).efi; \
> > >>  ln -sf $(T)-$(XEN_FULLVERSION).efi 
> > >> $(D)$(EFI_DIR)/$(T).efi; \
> > >> 
> > >> Either fix works.
> > > 
> > > This is fine.
> > > 
> > > Reviewed-by: Stefano Stabellini 
> > 
> > But I hope only with indentation properly cleaned up.
> 
> Like this:
> 
> 
> >From cc3edf6c2614fa69ab1d33c38a44a10c0f4a50e8 Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk 
> Date: Wed, 21 Sep 2016 11:39:44 -0400
> Subject: [PATCH v2] Makefile: fix (again) EFI part of "symbols: Generate an
>  xen-sym.map
> 
> This is a follow-up to commit d14fffcc6a7c054db9e337026a3c850152244ac4
> "fix EFI part of "symbols: Generate an xen-sym.map" which fixed most of
> the issues.
> 
> However we still have an issue - The file being installed (xen.efi.map)
> does not exist in an ARM64 build (the xen.efi is linked againts xen).
> 
> The fix can be done two ways:
>  a) See if xen.efi.map exists and then copy it
>  b) Or link xen.efi.map to xen-syms.map (similar to how xen.efi is linked
> against xen).
> 
> The patch chooses the first.
> 
> Reviewed-by: Stefano Stabellini 
> Reported-by: Jan Beulich 
> Signed-off-by: Konrad Rzeszutek Wilk 
> ---
> Cc: Julien Grall 
> Cc: Stefano Stabellini 
> 
> v1: First submission
> v2: Use the b) instead of a) option.
> Fix indentations.

Thanks. I had already fixed up the patch and committed it.

Cheers,

Stefano


>  xen/Makefile | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/Makefile b/xen/Makefile
> index c511330..54a3bc8 100644
> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -67,7 +67,9 @@ _install: $(TARGET)$(CONFIG_XEN_INSTALL_SUFFIX)
>   if [ -r $(TARGET).efi -a -n '$(EFI_DIR)' ]; then \
>   [ -d $(D)$(EFI_DIR) ] || $(INSTALL_DIR) $(D)$(EFI_DIR); \
>   $(INSTALL_DATA) $(TARGET).efi 
> $(D)$(EFI_DIR)/$(T)-$(XEN_FULLVERSION).efi; \
> - $(INSTALL_DATA) $(TARGET).efi.map 
> $(D)$(DEBUG_DIR)/$(T)-$(XEN_FULLVERSION).efi.map; \
> + if [ -e $(TARGET).efi.map ]; then \
> +$(INSTALL_DATA) $(TARGET).efi.map 
> $(D)$(DEBUG_DIR)/$(T)-$(XEN_FULLVERSION).efi.map; \
> + fi; \
>   ln -sf $(T)-$(XEN_FULLVERSION).efi 
> $(D)$(EFI_DIR)/$(T)-$(XEN_VERSION).$(XEN_SUBVERSION).efi; \
>   ln -sf $(T)-$(XEN_FULLVERSION).efi 
> $(D)$(EFI_DIR)/$(T)-$(XEN_VERSION).efi; \
>   ln -sf $(T)-$(XEN_FULLVERSION).efi $(D)$(EFI_DIR)/$(T).efi; \
 

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

Re: [Xen-devel] [PATCH] fix EFI part of "symbols: Generate an xen-sym.map"

2016-10-10 Thread Konrad Rzeszutek Wilk

On Mon, Oct 10, 2016 at 01:28:16AM -0600, Jan Beulich wrote:
> >>> On 07.10.16 at 19:57,  wrote:
> > On Wed, 21 Sep 2016, Konrad Rzeszutek Wilk wrote:
> >> On Wed, Sep 21, 2016 at 10:04:21AM -0600, Jan Beulich wrote:
> >> > >>> On 21.09.16 at 17:59,  wrote:
> >> > > The fix can be done two ways:
> >> > >  a) See if xen.efi.map exists and then copy it
> >> > >  b) Or link xen.efi.map to xen-syms.map (similar to how xen.efi is 
> >> > > linked
> >> > > against xen).
> >> > > 
> >> > > The patch chooses the latter.
> >> > 
> >> > Well, if the ARM maintainers like that ... I don't really see a point in
> >> > installing the same file twice without its second incarnation having a
> >> > specific purpose.
> >> 
> >> I also have the a) part ready, which is simple:
> >> 
> >> 
> >> diff --git a/xen/Makefile b/xen/Makefile
> >> index e989a20..678f188 100644
> >> --- a/xen/Makefile
> >> +++ b/xen/Makefile
> >> @@ -67,7 +67,9 @@ _install: $(TARGET)$(CONFIG_XEN_INSTALL_SUFFIX)
> >>if [ -r $(TARGET).efi -a -n '$(EFI_DIR)' ]; then \
> >>[ -d $(D)$(EFI_DIR) ] || $(INSTALL_DIR) $(D)$(EFI_DIR); \
> >>$(INSTALL_DATA) $(TARGET).efi 
> >> $(D)$(EFI_DIR)/$(T)-$(XEN_FULLVERSION).efi; \
> >> -  $(INSTALL_DATA) $(TARGET).efi.map 
> >> $(D)$(DEBUG_DIR)/$(T)-$(XEN_FULLVERSION).efi.map; \
> >> +if [ -e $(TARGET).efi.map ]; then \
> >> +  $(INSTALL_DATA) $(TARGET).efi.map 
> >> $(D)$(DEBUG_DIR)/$(T)-$(XEN_FULLVERSION).efi.map; \
> >> +fi; \
> >>ln -sf $(T)-$(XEN_FULLVERSION).efi 
> >> $(D)$(EFI_DIR)/$(T)-$(XEN_VERSION).$(XEN_SUBVERSION).efi; \
> >>ln -sf $(T)-$(XEN_FULLVERSION).efi 
> >> $(D)$(EFI_DIR)/$(T)-$(XEN_VERSION).efi; \
> >>ln -sf $(T)-$(XEN_FULLVERSION).efi $(D)$(EFI_DIR)/$(T).efi; \
> >> 
> >> Either fix works.
> > 
> > This is fine.
> > 
> > Reviewed-by: Stefano Stabellini 
> 
> But I hope only with indentation properly cleaned up.

Like this:


From cc3edf6c2614fa69ab1d33c38a44a10c0f4a50e8 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk 
Date: Wed, 21 Sep 2016 11:39:44 -0400
Subject: [PATCH v2] Makefile: fix (again) EFI part of "symbols: Generate an
 xen-sym.map

This is a follow-up to commit d14fffcc6a7c054db9e337026a3c850152244ac4
"fix EFI part of "symbols: Generate an xen-sym.map" which fixed most of
the issues.

However we still have an issue - The file being installed (xen.efi.map)
does not exist in an ARM64 build (the xen.efi is linked againts xen).

The fix can be done two ways:
 a) See if xen.efi.map exists and then copy it
 b) Or link xen.efi.map to xen-syms.map (similar to how xen.efi is linked
against xen).

The patch chooses the first.

Reviewed-by: Stefano Stabellini 
Reported-by: Jan Beulich 
Signed-off-by: Konrad Rzeszutek Wilk 
---
Cc: Julien Grall 
Cc: Stefano Stabellini 

v1: First submission
v2: Use the b) instead of a) option.
Fix indentations.
---
 xen/Makefile | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/xen/Makefile b/xen/Makefile
index c511330..54a3bc8 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -67,7 +67,9 @@ _install: $(TARGET)$(CONFIG_XEN_INSTALL_SUFFIX)
if [ -r $(TARGET).efi -a -n '$(EFI_DIR)' ]; then \
[ -d $(D)$(EFI_DIR) ] || $(INSTALL_DIR) $(D)$(EFI_DIR); \
$(INSTALL_DATA) $(TARGET).efi 
$(D)$(EFI_DIR)/$(T)-$(XEN_FULLVERSION).efi; \
-   $(INSTALL_DATA) $(TARGET).efi.map 
$(D)$(DEBUG_DIR)/$(T)-$(XEN_FULLVERSION).efi.map; \
+   if [ -e $(TARGET).efi.map ]; then \
+$(INSTALL_DATA) $(TARGET).efi.map 
$(D)$(DEBUG_DIR)/$(T)-$(XEN_FULLVERSION).efi.map; \
+   fi; \
ln -sf $(T)-$(XEN_FULLVERSION).efi 
$(D)$(EFI_DIR)/$(T)-$(XEN_VERSION).$(XEN_SUBVERSION).efi; \
ln -sf $(T)-$(XEN_FULLVERSION).efi 
$(D)$(EFI_DIR)/$(T)-$(XEN_VERSION).efi; \
ln -sf $(T)-$(XEN_FULLVERSION).efi $(D)$(EFI_DIR)/$(T).efi; \
-- 
2.5.5

> 
> Jan
> 

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

Re: [Xen-devel] [PATCH for-4.8] ipxe: update to newer commit

2016-10-10 Thread Juergen Schinker

and where have you applied that patch ? is it xen-4.8-rc1 ?

do I have to apply that patch ?

do I need to check out another tag ?

do I have to wait a week?

- On 10 Oct, 2016, at 16:33, Wei Liu wei.l...@citrix.com wrote:

> Sure. I will check ipxe mailing list in one week.
> 
> Wei.

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

Re: [Xen-devel] [PATCH for-4.8] ipxe: update to newer commit

2016-10-10 Thread Boris Ostrovsky

On 10/10/2016 12:33 PM, Wei Liu wrote:
> On Mon, Oct 10, 2016 at 04:51:13PM +0100, Ian Jackson wrote:
>> Wei Liu writes ("Re: [PATCH for-4.8] ipxe: update to newer commit"):
>>> On Mon, Oct 10, 2016 at 04:34:31PM +0100, Ian Jackson wrote:
 How did you choose 827dd1bfee67daa683935ce65316f7e0f057fe1c ?
>>> That's the latest commit -- since upstream wants us to always use the
>>> latest, I just picked that one.
>>>
>>> I built that commit with gcc 4.9 and gcc 6.1, both compiled OK.
>>> Realistically I don't expect issues with nic boot roms -- those are the
>>> only things we really use AFAICT.
>> Err, good.  Well, perhaps we can wait a week and see if anyone reports
>> hideous breakage in that ipxe revision ?
>>
> Sure. I will check ipxe mailing list in one week.

FWIW, here is the patch that I used to pacify gcc.

-boris
--- ./src/core/stringextra.c.orig	2016-09-01 13:32:19.324143538 -0400
+++ ./src/core/stringextra.c	2016-09-01 13:35:00.948147391 -0400
@@ -186,7 +186,7 @@
 {
 	char *sbegin, *send;
 
-	sbegin  = s ? s : ___strtok;
+	sbegin  = s;
 	if (!sbegin) {
 		return NULL;
 	}
--- ./src/include/nic.h.orig	2016-09-01 13:34:13.587146262 -0400
+++ ./src/include/nic.h	2016-09-01 14:02:19.043186446 -0400
@@ -199,7 +199,8 @@
 
 #undef DRIVER
 #define DRIVER(_name_text,_unused2,_unused3,_name,_probe,_disable)	  \
-	static const char _name ## _text[] = _name_text;		  \
+	static __attribute__ (( unused )) const char			\
+	_name ## _text[] = _name_text;		  \
 	static inline int		  \
 	_name ## _probe ( struct nic *nic, void *hwdev ) {		  \
 		return _probe ( nic, hwdev );  \
--- ./src/hci/mucurses/windows.c.orig	2016-09-01 13:34:04.834146053 -0400
+++ ./src/hci/mucurses/windows.c	2016-09-01 14:11:07.750199052 -0400
@@ -16,9 +16,6 @@
  * @ret rc	return status code
  */
 int delwin ( WINDOW *win ) {
-	if ( win == NULL )
-		return ERR;
-
 	/* I think we should blank the region covered by the window -
 	   ncurses doesn't do this, but they have a buffer, so they
 	   may just be deleting from an offscreen context whereas we
@@ -49,8 +46,6 @@
 WINDOW *derwin ( WINDOW *parent, int nlines, int ncols,
 	 		  	 int begin_y, int begin_x ) {
 	WINDOW *child;
-	if ( parent == NULL )
-		return NULL;
 	if ( ( child = malloc( sizeof( WINDOW ) ) ) == NULL )
 		return NULL;
 	if ( ( (unsigned)ncols > parent->width ) || 
@@ -73,8 +68,6 @@
  */
 WINDOW *dupwin ( WINDOW *orig ) {
 	WINDOW *copy;
-	if ( orig == NULL )
-		return NULL;
 	if ( ( copy = malloc( sizeof( WINDOW ) ) ) == NULL )
 		return NULL;
 	copy->scr = orig->scr;
@@ -97,8 +90,6 @@
  * @ret rc	return status code
  */
 int mvwin ( WINDOW *win, int y, int x ) {
-	if ( win == NULL )
-		return ERR;
 	if ( ( ( (unsigned)y + win->height ) > LINES ) ||
 	 ( ( (unsigned)x + win->width ) > COLS ) )
 		return ERR;
@@ -147,8 +138,6 @@
 WINDOW *subwin ( WINDOW *parent, int nlines, int ncols,
 			 int begin_y, int begin_x ) {
 	WINDOW *child;
-	if ( parent == NULL )
-		return NULL;
 	if ( ( child = malloc( sizeof( WINDOW ) ) ) == NULL )
 		return NULL;
 	child = newwin( nlines, ncols, begin_y, begin_x );
--- ./src/drivers/net/igb/igb_phy.c.orig	2016-09-01 14:06:58.151193101 -0400
+++ ./src/drivers/net/igb/igb_phy.c	2016-09-01 14:07:12.503193443 -0400
@@ -91,18 +91,18 @@
 	if (!(phy->ops.read_reg))
 		goto out;
 
-		ret_val = phy->ops.read_reg(hw, PHY_ID1, _id);
-		if (ret_val)
-			goto out;
+	ret_val = phy->ops.read_reg(hw, PHY_ID1, _id);
+	if (ret_val)
+		goto out;
 
-		phy->id = (u32)(phy_id << 16);
-		usec_delay(20);
-		ret_val = phy->ops.read_reg(hw, PHY_ID2, _id);
-		if (ret_val)
-			goto out;
+	phy->id = (u32)(phy_id << 16);
+	usec_delay(20);
+	ret_val = phy->ops.read_reg(hw, PHY_ID2, _id);
+	if (ret_val)
+		goto out;
 
-		phy->id |= (u32)(phy_id & PHY_REVISION_MASK);
-		phy->revision = (u32)(phy_id & ~PHY_REVISION_MASK);
+	phy->id |= (u32)(phy_id & PHY_REVISION_MASK);
+	phy->revision = (u32)(phy_id & ~PHY_REVISION_MASK);
 
 out:
 	return ret_val;
--- ./src/drivers/net/ath/ath5k/ath5k_phy.c.orig	2016-09-01 13:32:38.317143990 -0400
+++ ./src/drivers/net/ath/ath5k/ath5k_phy.c	2016-09-01 14:09:20.384196492 -0400
@@ -1219,12 +1219,12 @@
 
 	/* Update radio registers */
 	ath5k_hw_reg_write(ah, (phy_sig & ~(AR5K_PHY_SIG_FIRPWR)) |
-		AR5K_REG_SM(-1, AR5K_PHY_SIG_FIRPWR), AR5K_PHY_SIG);
+		AR5K_REG_SM(-1U, AR5K_PHY_SIG_FIRPWR), AR5K_PHY_SIG);
 
 	ath5k_hw_reg_write(ah, (phy_agc & ~(AR5K_PHY_AGCCOARSE_HI |
 			AR5K_PHY_AGCCOARSE_LO)) |
-		AR5K_REG_SM(-1, AR5K_PHY_AGCCOARSE_HI) |
-		AR5K_REG_SM(-127, AR5K_PHY_AGCCOARSE_LO), AR5K_PHY_AGCCOARSE);
+		AR5K_REG_SM(-1U, AR5K_PHY_AGCCOARSE_HI) |
+		AR5K_REG_SM(-127U, AR5K_PHY_AGCCOARSE_LO), AR5K_PHY_AGCCOARSE);
 
 	ath5k_hw_reg_write(ah, (phy_sat & ~(AR5K_PHY_ADCSAT_ICNT |
 			AR5K_PHY_ADCSAT_THR)) |
--- ./src/drivers/net/ath/ath5k/ath5k.c.orig	2016-09-01 13:32:28.652143760 -0400
+++ ./src/drivers/net/ath/ath5k/ath5k.c	2016-09-01 14:08:21.819195095 -0400
@@ -85,46 +85,6 @@
 	PCI_ROM(0x168c, 0x001d, "ath2417",

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

2016-10-10 Thread osstest service owner

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt  6 xen-boot fail REGR. vs. 101328
 test-armhf-armhf-xl-multivcpu  7 host-ping-check-xen fail REGR. vs. 101328

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail  like 101328
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101328
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101328
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 101328

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-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-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass

version targeted for testing:
 qemuu86e121ae75d10d0aa4ef76150e94a2e83bdac3e9
baseline version:
 qemuu48f592118ab42f83a1a7561c4bfd2b72a100f241

Last test of basis   101328  2016-10-07 21:44:14 Z2 days
Testing same since   101353  2016-10-10 11:13:43 Z0 days1 attempts


People who touched revisions under test:
  Alex BennÃ©e 
  Artyom Tarasenko 
  David Kiarie 
  Emilio G. Cota 
  HervÃ© Poussineau 
  Junlian Bell 
  Marc-AndrÃ© Lureau 
  Michal Privoznik 
  Paolo Bonzini 
  Peter Maydell 
  Peter Xu 
  TomÃ¡Å¡ GolembiovskÃ½ 

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-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass

[Xen-devel] [ovmf baseline-only test] 67856: all pass

2016-10-10 Thread Platform Team regression test user

This run is configured for baseline tests only.

flight 67856 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67856/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 87c04781d5a7d13ba3cae87daedd52fe71280f3f
baseline version:
 ovmf cf8140930ab23497f729b1750b5962fe18dbc685

Last test of basis67855  2016-10-10 07:48:15 Z0 days
Testing same since67856  2016-10-10 14:16:11 Z0 days1 attempts


People who touched revisions under test:
  Chao Zhang 
  Zhang, Chao B 

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



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

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

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


Push not applicable.


commit 87c04781d5a7d13ba3cae87daedd52fe71280f3f
Author: Zhang, Chao B 
Date:   Mon Oct 10 16:42:01 2016 +0800

SecurityPkg: SmmTcg2PhysicalPresenceLib: Fix GCC build failure

GCC is case sensitive. Also add BaseMemoryLib in INF.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Chao Zhang 
Reviewed-by: Gao Liming 
Reviewed-by: Long Qin 

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

Re: [Xen-devel] [Qemu-devel] [RFC QEMU PATCH 0/8] Implement vNVDIMM for Xen HVM guest

2016-10-10 Thread no-reply

Hi,

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

Message-id: 20161010003423.4333-1-haozhong.zh...@intel.com
Subject: [Qemu-devel] [RFC QEMU PATCH 0/8] Implement vNVDIMM for Xen HVM guest
Type: series

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

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
455b9b0 qmp: add a qmp command 'query-nvdimms' to get plugged NVDIMM devices
bea844c xen-hvm: create hotplug memory region for HVM guest
ba5ca9a hostmem: add a host memory backend for Xen
02dc103 nvdimm acpi: build and copy NVDIMM namespace devices to guest on Xen
a3e39ca nvdimm acpi: build and copy NFIT to guest on Xen
1671ab8 nvdimm acpi: do not use fw_cfg on Xen
f7fa2ca xen-hvm: add a function to copy ACPI to guest
d6a1929 nvdimm: do not initialize label_data if label_size is zero

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

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

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

Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen

2016-10-10 Thread Andrew Cooper

On 10/10/16 01:35, Haozhong Zhang wrote:
> Overview
> 
> This RFC kernel patch series along with corresponding patch series of
> Xen, QEMU and ndctl implements Xen vNVDIMM, which can map the host
> NVDIMM devices to Xen HVM domU as vNVDIMM devices.
>
> Xen hypervisor does not include an NVDIMM driver, so it needs the
> assistance from the driver in Dom0 Linux kernel to manage NVDIMM
> devices. We currently only supports NVDIMM devices in pmem mode.
>
> Design and Implementation
> =
> The complete design can be found at
>   https://lists.xenproject.org/archives/html/xen-devel/2016-07/msg01921.html.
>
> All patch series can be found at
>   Xen:  https://github.com/hzzhan9/xen.git nvdimm-rfc-v1
>   QEMU: https://github.com/hzzhan9/qemu.git xen-nvdimm-rfc-v1
>   Linux kernel: https://github.com/hzzhan9/nvdimm.git xen-nvdimm-rfc-v1
>   ndctl:https://github.com/hzzhan9/ndctl.git pfn-xen-rfc-v1
>
> Xen hypervisor needs assistance from Dom0 Linux kernel for following tasks:
> 1) Reserve an area on NVDIMM devices for Xen hypervisor to place
>memory management data structures, i.e. frame table and M2P table.
> 2) Report SPA ranges of NVDIMM devices and the reserved area to Xen
>hypervisor.

Please can we take a step back here before diving down a rabbit hole.

How do pblk/pmem regions appear in the E820 map at boot?  At the very
least, I would expect at least a large reserved region.

Is the MFN information (SPA in your terminology, so far as I can tell)
available in any static APCI tables, or are they only available as a
result of executing AML methods?

If the MFN information is only available via AML, then point 2) is
needed, although the reporting back to Xen should be restricted to a xen
component, rather than polluting the main device driver.

However, I can't see any justification for 1).  Dom0 should not be
involved in Xen's management of its own frame table and m2p.  The mfns
making up the pmem/pblk regions should be treated just like any other
MMIO regions, and be handed wholesale to dom0 by default.

~Andrew

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

Re: [Xen-devel] [PATCH for-4.8] ipxe: update to newer commit

2016-10-10 Thread Wei Liu

On Mon, Oct 10, 2016 at 04:51:13PM +0100, Ian Jackson wrote:
> Wei Liu writes ("Re: [PATCH for-4.8] ipxe: update to newer commit"):
> > On Mon, Oct 10, 2016 at 04:34:31PM +0100, Ian Jackson wrote:
> > > How did you choose 827dd1bfee67daa683935ce65316f7e0f057fe1c ?
> > 
> > That's the latest commit -- since upstream wants us to always use the
> > latest, I just picked that one.
> > 
> > I built that commit with gcc 4.9 and gcc 6.1, both compiled OK.
> > Realistically I don't expect issues with nic boot roms -- those are the
> > only things we really use AFAICT.
> 
> Err, good.  Well, perhaps we can wait a week and see if anyone reports
> hideous breakage in that ipxe revision ?
> 

Sure. I will check ipxe mailing list in one week.

Wei.

> Ian.

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

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

2016-10-10 Thread osstest service owner

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

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  0a9d8a57e1f9024459e613e831905d28ef72051a
baseline version:
 xen  78ff18c905318a9b1e5dd32662986f03b10a4e56

Last test of basis   101352  2016-10-10 11:01:28 Z0 days
Testing same since   101356  2016-10-10 14:02:50 Z0 days1 attempts


People who touched revisions under test:
  Wei Liu 

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



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=0a9d8a57e1f9024459e613e831905d28ef72051a
+ . ./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 
0a9d8a57e1f9024459e613e831905d28ef72051a
+ branch=xen-unstable-smoke
+ revision=0a9d8a57e1f9024459e613e831905d28ef72051a
+ . ./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
+ '[' x0a9d8a57e1f9024459e613e831905d28ef72051a = 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
++ :

Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen

2016-10-10 Thread Dan Williams

On Sun, Oct 9, 2016 at 11:32 PM, Haozhong Zhang
 wrote:
> On 10/09/16 20:45, Dan Williams wrote:
>> On Sun, Oct 9, 2016 at 5:35 PM, Haozhong Zhang  
>> wrote:
>> > Overview
>> > 
>> > This RFC kernel patch series along with corresponding patch series of
>> > Xen, QEMU and ndctl implements Xen vNVDIMM, which can map the host
>> > NVDIMM devices to Xen HVM domU as vNVDIMM devices.
>> >
>> > Xen hypervisor does not include an NVDIMM driver, so it needs the
>> > assistance from the driver in Dom0 Linux kernel to manage NVDIMM
>> > devices. We currently only supports NVDIMM devices in pmem mode.
>> >
>> > Design and Implementation
>> > =
>> > The complete design can be found at
>> >   
>> > https://lists.xenproject.org/archives/html/xen-devel/2016-07/msg01921.html.
>>
>> The KVM enabling for persistent memory does not need this support from
>> the kernel, and as far as I can see neither does Xen. If the
>> hypervisor needs to reserve some space it can simply trim the amount
>> that it hands to the guest.
>>
>
> Xen does not have the NVDIMM driver, so it cannot operate on NVDIMM
> devices by itself. Instead it relies on the driver in Dom0 Linux to
> probe NVDIMM and make the reservation.

I'm missing something because the design document talks about mmap'ing
files on a DAX filesystem.  So, I'm assuming it is similar to the KVM
NVDIMM virtualization case where an mmap range in dom0 is translated
into a guest physical range.  The suggestion is to reserve some memory
out of that mapping rather than introduce a new info block /
reservation type to the sub-system.

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

Re: [Xen-devel] [PATCH v2 for-4.8] libelf: fix symtab/strtab loading for 32bit domains

2016-10-10 Thread Ian Jackson

Roger Pau Monne writes ("[PATCH v2 for-4.8] libelf: fix symtab/strtab loading 
for 32bit domains"):
> Commit ed04ca introduced a bug in the symtab/strtab loading for 32bit
> guests, that corrupted the section headers array due to the padding
> introduced by the elf_shdr union.
> 
> The Elf section header array on 32bit should be accessible as an array of
> Elf32_Shdr elements, and the union with Elf64_Shdr done in elf_shdr was
> breaking this due to size differences between Elf32_Shdr and Elf64_Shdr.
> 
> Fix this by copying each section header one by one, and using the proper
> size depending on the bitness of the guest kernel. While there, also fix
> elf_parse_bsdsyms so that it takes into account the size of the elf_ehdr
> struct instead of the native Elf header size.
> 
> Reported-by: Brian Marcotte 
> Signed-off-by: Roger Pau Monné 

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH v2 28/30] xen/x86: add MSI-X emulation to PVHv2 Dom0

2016-10-10 Thread Jan Beulich

>>> On 27.09.16 at 17:57,  wrote:
> --- a/xen/arch/x86/hvm/vmsi.c
> +++ b/xen/arch/x86/hvm/vmsi.c
> @@ -40,6 +40,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  static void vmsi_inj_irq(
>  struct vlapic *target,
> @@ -1162,3 +1163,500 @@ struct hvm_pt_handler_init hvm_pt_msi_init = {
>  .handlers = vmsi_handler,
>  .init = vmsi_group_init,
>  };
> +
> +/* MSI-X */

This comment is misleading - the entire file deals with MSI-X only.

Other than that I'm as frightened here of the code lifted from qemu
as I have expressed already on the earlier patches, and I'd really
like to understand better why all this is needed when it wasn't
needed for PVHv1, when so far I had understood that it's mainly
boot and AP bringup (as documented in hvmlite.markdown) which
makes up the difference between them. And just to avoid
misunderstandings - I'm all for replacing hacked up bits of the v1
implementation, but I don't think transplanting the other half of
the split brain qemu/Xen model into Xen will result in a single,
well functioning brain.

Jan

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

[Xen-devel] [PATCH v2 for-4.8] libelf: fix symtab/strtab loading for 32bit domains

2016-10-10 Thread Roger Pau Monne

Commit ed04ca introduced a bug in the symtab/strtab loading for 32bit
guests, that corrupted the section headers array due to the padding
introduced by the elf_shdr union.

The Elf section header array on 32bit should be accessible as an array of
Elf32_Shdr elements, and the union with Elf64_Shdr done in elf_shdr was
breaking this due to size differences between Elf32_Shdr and Elf64_Shdr.

Fix this by copying each section header one by one, and using the proper
size depending on the bitness of the guest kernel. While there, also fix
elf_parse_bsdsyms so that it takes into account the size of the elf_ehdr
struct instead of the native Elf header size.

Reported-by: Brian Marcotte 
Signed-off-by: Roger Pau Monné 
---
Cc: Brian Marcotte 
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
Should be backported to Xen 4.7 stable branch.
---
Changes since v1:
 - No need to calculate shdr_size again, it's already fetched from the
   original elf header.
 - Remove shdr variable.
 - Use offsetof instead of subtracting two sizeofs.
 - Fix elf_parse_bsdsyms so that it takes into account the size of elf_ehdr
   instead of the size of the native elf header.
---
 xen/common/libelf/libelf-loader.c | 34 +++---
 1 file changed, 27 insertions(+), 7 deletions(-)

diff --git a/xen/common/libelf/libelf-loader.c 
b/xen/common/libelf/libelf-loader.c
index 2626a40..47699ec 100644
--- a/xen/common/libelf/libelf-loader.c
+++ b/xen/common/libelf/libelf-loader.c
@@ -174,8 +174,8 @@ void elf_parse_bsdsyms(struct elf_binary *elf, uint64_t 
pstart)
 /* Space to store the size of the elf image */
 sz = sizeof(uint32_t);
 
-/* Space for the elf and elf section headers */
-sz += elf_uval(elf, elf->ehdr, e_ehsize) +
+/* Space for the elf header and elf section headers */
+sz += sizeof(elf_ehdr) +
   ELF_BSDSYM_SECTIONS * elf_uval(elf, elf->ehdr, e_shentsize);
 sz = elf_round_up(elf, sz);
 
@@ -258,13 +258,13 @@ static void elf_load_bsdsyms(struct elf_binary *elf)
 struct {
 elf_ehdr header;
 elf_shdr section[ELF_BSDSYM_SECTIONS];
-} __attribute__((packed)) elf_header;
+} elf_header;
 } __attribute__((packed)) header;
 
 ELF_HANDLE_DECL(elf_ehdr) header_handle;
-unsigned long shdr_size;
+unsigned long shdr_size, ehdr_size;
 ELF_HANDLE_DECL(elf_shdr) section_handle;
-unsigned int link, rc;
+unsigned int link, rc, i;
 elf_ptrval header_base;
 elf_ptrval elf_header_base;
 elf_ptrval symtab_base;
@@ -394,15 +394,35 @@ do {  
  \
 header.size = strtab_base + elf_uval(elf, section_handle, sh_size) -
   elf_header_base;
 
-/* Load the headers. */
+/* Load the size plus elf header. */
+ehdr_size = offsetof(typeof(header), elf_header.section);
 rc = elf_load_image(elf, header_base, ELF_REALPTR2PTRVAL(),
-sizeof(header), sizeof(header));
+ehdr_size, ehdr_size);
 if ( rc != 0 )
 {
 elf_mark_broken(elf, "unable to load ELF headers into guest memory");
 return;
 }
 
+/*
+ * Load the section headers.
+ *
+ * NB: this _must_ be done one by one, and taking the bitness into account,
+ * so that the guest can treat this as an array of type Elf{32/64}_Shdr.
+ */
+for ( i = 0; i < ELF_BSDSYM_SECTIONS; i++ )
+{
+rc = elf_load_image(elf, header_base + ehdr_size + shdr_size * i,
+ELF_REALPTR2PTRVAL(_header.section[i]),
+shdr_size, shdr_size);
+if ( rc != 0 )
+{
+elf_mark_broken(elf,
+"unable to load ELF section header into guest memory");
+return;
+}
+}
+
 /* Remove permissions from elf_memcpy_safe. */
 elf->caller_xdest_base = NULL;
 elf->caller_xdest_size = 0;
-- 
2.7.4 (Apple Git-66)


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

Re: [Xen-devel] [PATCH v2 0/9] Rework gcov support in Xen

2016-10-10 Thread Jan Beulich

>>> On 10.10.16 at 17:47,  wrote:
> Wei Liu writes ("[PATCH v2 0/9] Rework gcov support in Xen"):
>> Since the hypervisor interface is sysctl, we have the liberty to not
>> care about backward compatibility. This series completely rewrites the
>> gcov support inside Xen.
> 
> I have looked at these patches.  One of them seemed in my bailiwick -
> the libxc tools patch, which I have acked.
> 
> If you feel my ack is needed for any of the build system parts, please
> feel free to add it.  I've looked at those and they don't seem
> controversial to me.
> 
> Can someone hypervisor-side confirm that this functionality is really
> disabled when the Kconfig is off, and so we don't need to worry about
> its security status ?

Well, I think I've done so by acking most of the patches. But in
any event this

subdir-$(CONFIG_GCOV) += gcov

in xen/common/Makefile ensures none of the code in that directory
would get built.

Jan


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

Re: [Xen-devel] [PATCH for-4.8] ipxe: update to newer commit

2016-10-10 Thread Ian Jackson

Wei Liu writes ("Re: [PATCH for-4.8] ipxe: update to newer commit"):
> On Mon, Oct 10, 2016 at 04:34:31PM +0100, Ian Jackson wrote:
> > How did you choose 827dd1bfee67daa683935ce65316f7e0f057fe1c ?
> 
> That's the latest commit -- since upstream wants us to always use the
> latest, I just picked that one.
> 
> I built that commit with gcc 4.9 and gcc 6.1, both compiled OK.
> Realistically I don't expect issues with nic boot roms -- those are the
> only things we really use AFAICT.

Err, good.  Well, perhaps we can wait a week and see if anyone reports
hideous breakage in that ipxe revision ?

Ian.

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

Re: [Xen-devel] [PATCH v2 0/9] Rework gcov support in Xen

2016-10-10 Thread Ian Jackson

Wei Liu writes ("[PATCH v2 0/9] Rework gcov support in Xen"):
> Since the hypervisor interface is sysctl, we have the liberty to not
> care about backward compatibility. This series completely rewrites the
> gcov support inside Xen.

I have looked at these patches.  One of them seemed in my bailiwick -
the libxc tools patch, which I have acked.

If you feel my ack is needed for any of the build system parts, please
feel free to add it.  I've looked at those and they don't seem
controversial to me.

Can someone hypervisor-side confirm that this functionality is really
disabled when the Kconfig is off, and so we don't need to worry about
its security status ?

Thanks,
Ian.

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

Re: [Xen-devel] [PATCH for-4.8] ipxe: update to newer commit

2016-10-10 Thread Wei Liu

On Mon, Oct 10, 2016 at 04:34:31PM +0100, Ian Jackson wrote:
> Wei Liu writes ("[PATCH for-4.8] ipxe: update to newer commit"):
> > The current commit in tree is rather old. It has come to a point that
> > cherry-picking commits from upstream isn't trivial anymore.
> > 
> > There is long term plan to track ipxe upstream, but for 4.8 release, we
> > should just update ipxe to a newer commit (they are using rolling
> > release model now).
> > 
> > Forward-port the one boot prompt patch that is still relevant and retire
> > the rest which are already in upstream.
> 
> As I said IRL, I think this is a goiod approach.  (I hadn't realised
> we were cloning it rather than getting a tarball from xenbits...)
> 
> How did you choose 827dd1bfee67daa683935ce65316f7e0f057fe1c ?
> 

That's the latest commit -- since upstream wants us to always use the
latest, I just picked that one.

I built that commit with gcc 4.9 and gcc 6.1, both compiled OK.
Realistically I don't expect issues with nic boot roms -- those are the
only things we really use AFAICT.

Wei.

> Ian.

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

Re: [Xen-devel] [PATCH v2 6/9] gcov: userspace tools to extract and split gcov data

2016-10-10 Thread Ian Jackson

Wei Liu writes ("[PATCH v2 6/9] gcov: userspace tools to extract and split gcov 
data"):
> Provide two tools: a small C program to extract data from hypervisor and
> a python script to split data into multiple files.

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH for-4.8] ipxe: update to newer commit

2016-10-10 Thread Ian Jackson

Wei Liu writes ("[PATCH for-4.8] ipxe: update to newer commit"):
> The current commit in tree is rather old. It has come to a point that
> cherry-picking commits from upstream isn't trivial anymore.
> 
> There is long term plan to track ipxe upstream, but for 4.8 release, we
> should just update ipxe to a newer commit (they are using rolling
> release model now).
> 
> Forward-port the one boot prompt patch that is still relevant and retire
> the rest which are already in upstream.

As I said IRL, I think this is a goiod approach.  (I hadn't realised
we were cloning it rather than getting a tarball from xenbits...)

How did you choose 827dd1bfee67daa683935ce65316f7e0f057fe1c ?

Ian.

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

Re: [Xen-devel] [PATCH v2 29/30] xen/x86: allow PVHv2 to perform foreign memory mappings

2016-10-10 Thread George Dunlap

On 10/10/16 15:50, Jan Beulich wrote:
 On 10.10.16 at 16:27,  wrote:
>> On 10/10/16 15:21, Jan Beulich wrote:
>> On 27.09.16 at 17:57,  wrote:
 --- a/xen/arch/x86/mm/p2m.c
 +++ b/xen/arch/x86/mm/p2m.c
 @@ -2793,7 +2793,7 @@ int p2m_add_foreign(struct domain *tdom, unsigned 
 long fgfn,
  struct domain *fdom;
  
  ASSERT(tdom);
 -if ( foreigndom == DOMID_SELF || !is_pvh_domain(tdom) )
 +if ( foreigndom == DOMID_SELF || !has_hvm_container_domain(tdom) )
  return -EINVAL;
>>>
>>> Can PV domains make it here? If not, dropping the predicate would
>>> seem the better adjustment.
>>
>> Is there any chance that in the future PV domains might accidentally get
>> here because of some other changes in the future?  If so, leaving the
>> predicate seems like a sensible precaution to reduce the risk of XSAs
>> down the road, since we're doing a load of checking already anyway. ;-)
> 
> In which case I'd still prefer to extend the ASSERT() right ahead of
> the if(). But you're the maintainer of this code, so you know best.

ASSERT()s and BUG_ON()s are not suitable for checks with security
implications.  Unless we specifically test for PV guests making this
hypercall, both are very likely to slip entirely through any testing we
do; in which case the former would become a full security issue, and the
latter becomes a DoS.

 -George


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

Re: [Xen-devel] [PATCH v2 29/30] xen/x86: allow PVHv2 to perform foreign memory mappings

2016-10-10 Thread Jan Beulich

>>> On 10.10.16 at 16:27,  wrote:
> On 10/10/16 15:21, Jan Beulich wrote:
> On 27.09.16 at 17:57,  wrote:
>>> --- a/xen/arch/x86/mm/p2m.c
>>> +++ b/xen/arch/x86/mm/p2m.c
>>> @@ -2793,7 +2793,7 @@ int p2m_add_foreign(struct domain *tdom, unsigned 
>>> long fgfn,
>>>  struct domain *fdom;
>>>  
>>>  ASSERT(tdom);
>>> -if ( foreigndom == DOMID_SELF || !is_pvh_domain(tdom) )
>>> +if ( foreigndom == DOMID_SELF || !has_hvm_container_domain(tdom) )
>>>  return -EINVAL;
>> 
>> Can PV domains make it here? If not, dropping the predicate would
>> seem the better adjustment.
> 
> Is there any chance that in the future PV domains might accidentally get
> here because of some other changes in the future?  If so, leaving the
> predicate seems like a sensible precaution to reduce the risk of XSAs
> down the road, since we're doing a load of checking already anyway. ;-)

In which case I'd still prefer to extend the ASSERT() right ahead of
the if(). But you're the maintainer of this code, so you know best.

Jan


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

Re: [Xen-devel] [PATCH v2 5/9] gcov: add new interface and 3.4 and 4.7 format support

2016-10-10 Thread Wei Liu

On Mon, Oct 10, 2016 at 02:11:58PM +0100, Wei Liu wrote:
[...]
> > > +
> > > +#include "gcov.h"
> > > +
> > > +/*
> > > + * __gcov_init is called by gcc-generated constructor code for each 
> > > object
> > > + * file compiled with -fprofile-arcs.
> > > + *
> > > + * Although this function is called only during initialization is called 
> > > from
> > > + * a .text section which is still present after initialization so not 
> > > declare
> > > + * as __init.
> > 
> > I don't follow - we do such references elsewhere, so I can't see a
> > reason not to follow that model here too as long the call here
> > happens before .init.* get discarded.
> > 
> 
> This is residual from previous implementation. I haven't checked if the
> statement is true or not. If this statement is not true I'm happy to
> make corresponding adjustments.

It turns out that annotating __gcov_init as __init works. I will make
that adjustment in next version.

Wei.

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

Re: [Xen-devel] [PATCH v2 29/30] xen/x86: allow PVHv2 to perform foreign memory mappings

2016-10-10 Thread George Dunlap

On 10/10/16 15:21, Jan Beulich wrote:
 On 27.09.16 at 17:57,  wrote:
>> --- a/xen/arch/x86/mm/p2m.c
>> +++ b/xen/arch/x86/mm/p2m.c
>> @@ -2793,7 +2793,7 @@ int p2m_add_foreign(struct domain *tdom, unsigned long 
>> fgfn,
>>  struct domain *fdom;
>>  
>>  ASSERT(tdom);
>> -if ( foreigndom == DOMID_SELF || !is_pvh_domain(tdom) )
>> +if ( foreigndom == DOMID_SELF || !has_hvm_container_domain(tdom) )
>>  return -EINVAL;
> 
> Can PV domains make it here? If not, dropping the predicate would
> seem the better adjustment.

Is there any chance that in the future PV domains might accidentally get
here because of some other changes in the future?  If so, leaving the
predicate seems like a sensible precaution to reduce the risk of XSAs
down the road, since we're doing a load of checking already anyway. ;-)

At the moment, nobody's going to get past he "is_hardware_domain()"
except dom0, but presumably that will change once we get driver domains
implemented.

 -George

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

Re: [Xen-devel] [PATCH v2 29/30] xen/x86: allow PVHv2 to perform foreign memory mappings

2016-10-10 Thread Jan Beulich

>>> On 27.09.16 at 17:57,  wrote:
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -2793,7 +2793,7 @@ int p2m_add_foreign(struct domain *tdom, unsigned long 
> fgfn,
>  struct domain *fdom;
>  
>  ASSERT(tdom);
> -if ( foreigndom == DOMID_SELF || !is_pvh_domain(tdom) )
> +if ( foreigndom == DOMID_SELF || !has_hvm_container_domain(tdom) )
>  return -EINVAL;

Can PV domains make it here? If not, dropping the predicate would
seem the better adjustment.

Jan


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

Re: [Xen-devel] [PATCH v2 27/30] x86/msixtbl: disable MSI-X intercepts for domains without an ioreq server

2016-10-10 Thread Jan Beulich

>>> On 27.09.16 at 17:57,  wrote:
> The current msixtbl intercepts only partially trap MSI-X accesses, but are
> not complete, there's missing logic in order to setup PIRQs and bind them to
> domains. Disable them for domains without at least an ioreq server (PVH).

So what if a server registers later on?

> --- a/xen/arch/x86/hvm/ioreq.c
> +++ b/xen/arch/x86/hvm/ioreq.c
> @@ -772,6 +772,17 @@ int hvm_destroy_ioreq_server(struct domain *d, 
> ioservid_t id)
>  return rc;
>  }
>  
> +int hvm_has_ioreq_server(struct domain *d)

bool

> +{
> +int empty;

bool

> --- a/xen/drivers/passthrough/io.c
> +++ b/xen/drivers/passthrough/io.c
> @@ -24,6 +24,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 

Please group with the other asm/hvm/ ones.

Jan


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

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

2016-10-10 Thread osstest service owner

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 87c04781d5a7d13ba3cae87daedd52fe71280f3f
baseline version:
 ovmf cf8140930ab23497f729b1750b5962fe18dbc685

Last test of basis   101348  2016-10-10 02:50:06 Z0 days
Testing same since   101351  2016-10-10 09:19:53 Z0 days1 attempts


People who touched revisions under test:
  Chao Zhang 
  Zhang, Chao B 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 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=87c04781d5a7d13ba3cae87daedd52fe71280f3f
+ . ./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 
87c04781d5a7d13ba3cae87daedd52fe71280f3f
+ branch=ovmf
+ revision=87c04781d5a7d13ba3cae87daedd52fe71280f3f
+ . ./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
+ '[' x87c04781d5a7d13ba3cae87daedd52fe71280f3f = 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
++ :

Re: [Xen-devel] [BUG] Re: testing XEN-4.8-rc1

2016-10-10 Thread Wei Liu

On Mon, Oct 10, 2016 at 10:06:19AM -0400, Boris Ostrovsky wrote:
> On 10/10/2016 06:00 AM, Wei Liu wrote:
> > On Mon, Oct 10, 2016 at 10:36:04AM +0100, Juergen Schinker wrote:
> >> Ok then on Debian testing 
> >>
> >>  ii  gcc-6 6.2.0-5 
> >>  amd64GNU C compiler
> >>
> > Right, I think I know why it didn't build for you.
> >
> > We've got some medium to long term plan for it, but for this release we
> > need something to fix it as quick as we can.
> >
> > Let me try to write a patch.
> >
> 
> This is a compiler issue:
> 
> https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg00100.html
> 
> I said I'd try to fix it and never did as I got distracted by other
> things, sorry. I will try to get to this in a couple of weeks.
> 

That's going to be in next version of Xen -- in the mean time I've
written a patch for 4.8.

See <1476103858-8305-1-git-send-email-wei.l...@citrix.com>.

Wei.

> -boris
> 

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

Re: [Xen-devel] [BUG] Re: testing XEN-4.8-rc1

2016-10-10 Thread Boris Ostrovsky

On 10/10/2016 06:00 AM, Wei Liu wrote:
> On Mon, Oct 10, 2016 at 10:36:04AM +0100, Juergen Schinker wrote:
>> Ok then on Debian testing 
>>
>>  ii  gcc-6 6.2.0-5   
>>amd64GNU C compiler
>>
> Right, I think I know why it didn't build for you.
>
> We've got some medium to long term plan for it, but for this release we
> need something to fix it as quick as we can.
>
> Let me try to write a patch.
>

This is a compiler issue:

https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg00100.html

I said I'd try to fix it and never did as I got distracted by other
things, sorry. I will try to get to this in a couple of weeks.

-boris


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

Re: [Xen-devel] [PATCH v2 26/30] xen/x86: add PCIe emulation

2016-10-10 Thread Jan Beulich

>>> On 27.09.16 at 17:57,  wrote:
> Add a new MMIO handler that traps accesses to PCIe regions, as discovered by
> Xen from the MCFG ACPI table. The handler used is the same as the one used
> for accesses to the IO PCI configuration space.

Both in the title and in the code you use PCIe when you really mean
MCFG / MMCFG. Please don't misguide people like this: PCI-X uses
extended config space too afaik.

> --- a/xen/arch/x86/hvm/io.c
> +++ b/xen/arch/x86/hvm/io.c
> @@ -46,6 +46,8 @@
>  #include 
>  #include 
>  
> +#include "../x86_64/mmconfig.h"

Please don't. If declaration there are needed here, move them into
xen/include/asm-x86/.

> +static struct acpi_mcfg_allocation *pcie_find_mmcfg(unsigned long addr)
> +{
> +int i;

unsigned int

> +static void pcie_decode_addr(unsigned long addr, unsigned int *bus,

By the time you gets here what gets passed in is not an address
anymore, so please don't name the parameter this way.

> + unsigned int *slot, unsigned int *func,
> + unsigned int *reg)
> +{
> +
> +*bus = (addr >> 20) & 0xff;
> +*slot = (addr >> 15) & 0x1f;
> +*func = (addr >> 12) & 0x7;

Any reason you can't use pci_mmcfg_decode() here instead of
these various open coded numbers, or at least some derived
logic?

> +static int pcie_range(struct vcpu *v, unsigned long addr)
> +{
> +
> +return pcie_find_mmcfg(addr) != NULL ? 1 : 0;

No need for the conditional expression.

Jan

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

Re: [Xen-devel] [Resend PATCH 1/2] Xen/Keyhandler: Make keyhandler always run in tasklet

2016-10-10 Thread Konrad Rzeszutek Wilk

On Sat, Oct 08, 2016 at 11:26:44AM +0800, Lan Tianyu wrote:
> On 2016年10月06日 20:52, Jan Beulich wrote:
>  On 30.09.16 at 04:19,  wrote:
> >> @@ -87,10 +89,10 @@ void handle_keypress(unsigned char key, struct 
> >> cpu_user_regs *regs)
> >>  if ( key >= ARRAY_SIZE(key_table) || !(h = _table[key])->fn )
> >>  return;
> >>  
> >> -if ( !in_irq() || h->irq_callback )
> >> +if ( h->irq_callback )
> > 
> > Please make subject/description reflect this: You don't _always_
> > force the use of the tasklet.
> 
> Ok. I also find register_irq_keyhandler() isn't called anywhere in
> current code and that means none uses irq_callback. Can we remove it?

But it is. See IRQ_KEYHANDLER
> 
> > 
> > And then I don't think we want the debugkey sysctl get processed
> > asynchronously - the sysctl should complete only when the key has
> > been fully handled, in order to not interfere with a subsequent one
> > (namely the one retrieving the log buffer).
> 
> We may introduce a new parameter for handle_keypress() to specify
> whether it should schedule a tasklet to run keyhandler or not. For
> sysctl case, it should be the later one.
> 
> -- 
> Best regards
> Tianyu Lan

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

Re: [Xen-devel] [PATCHv2 0/2] xen/privcmd: prevent page migration for hypercall buffers

2016-10-10 Thread David Vrabel

On 04/08/16 16:16, David Vrabel wrote:
> Currently libxencall using mlocked buffers for hypercall buffers.
> This pages are subject to compaction and page migration. A userspace
> process may see a hypercall fail with -EFAULT if a page backing a
> hypercall buffer is in the process of being migrated.
> 
> Page migration can be prevented by taking an additional reference to
> the page.
> 
> There are three possible ways to do this:
> 
> 1. Add a new device which when mmap()'d populated the VMA with
>suitable memory that has an additional reference.  This would give
>VMAs that have appropriate properties set (e.g., VM_DONTCOPY)
>without having to do additional madvise() calls.
> 
> 2. Add a new ioctl to privcmd to populate a VMA with suitably
>ref-counted pages.  However, mmap() on privcmd is already used for
>foreign mappings and the VMA properties for hypercall buffers and
>foreign mappings might need to be different and the handling of
>unmap will need to be different.  This might be tricky.
> 
> 3. Add a pair of ioctls to privcmd to lock/unlock a buffer by
>getting/putting an additional reference to the page.  This is
>what's implemented in this series.

This method appears to be insufficient -- I'm still seeing very
occasional, spurious -EFAULT errors.

The easiest workaround is to set vm.compact_unevictable_allowed = 0.

David

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

Re: [Xen-devel] [PATCH v2 25/30] xen/x86: add all PCI devices to PVHv2 Dom0

2016-10-10 Thread Jan Beulich

>>> On 27.09.16 at 17:57,  wrote:
> --- a/xen/arch/x86/domain_build.c
> +++ b/xen/arch/x86/domain_build.c
> @@ -2378,6 +2378,25 @@ static int __init hvm_setup_acpi(struct domain *d)
>  return 0;
>  }
>  
> +static int __init hvm_setup_pci(struct domain *d)
> +{
> +struct pci_dev *pdev;
> +int rc;
> +
> +printk("** Adding PCI devices **\n");
> +
> +pcidevs_lock();
> +list_for_each_entry( pdev, >arch.pdev_list, domain_list )
> +{
> +rc = hwdom_add_device(pdev);

Considering the loop construct it is clear that the devices must
already have been added to the domain by the time you get here.
Hence the title (together with there not being any description) is
at least misleading.

Jan


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

Re: [Xen-devel] [PATCH v2 23/30] xen/x86: route legacy PCI interrupts to Dom0

2016-10-10 Thread Jan Beulich

>>> On 27.09.16 at 17:57,  wrote:
> This is done adding some Dom0 specific logic to the IO APIC emulation inside
> of Xen, so that writes to the IO APIC registers that should unmask an
> interrupt will take care of setting up this interrupt with Xen. A Dom0
> specific EIO handler also has to be used, since Xen doesn't know the
> topology of the PCI devices and it just has to passthrough what Dom0 does.

Without having looked at the patch (yet) I have a hard time seeing
the connection between EOI and PCI topology. I therefore think the
description needs improvement.

> --- a/xen/arch/x86/hvm/vioapic.c
> +++ b/xen/arch/x86/hvm/vioapic.c
> @@ -148,6 +148,29 @@ static void vioapic_write_redirent(
>  unmasked = unmasked && !ent.fields.mask;
>  }
>  
> +if ( is_hardware_domain(d) && unmasked )
> +{
> +int ret, gsi;
> +
> +/* Interrupt has been unmasked */
> +gsi = idx;
> +ret = mp_register_gsi(gsi, ent.fields.trig_mode, 
> ent.fields.polarity);
> +if ( ret && ret != -EEXIST )
> +{
> +gdprintk(XENLOG_WARNING,
> + "%s: error registering GSI %d\n", __func__, ret);

The message text suggests the number is the GSI, whereas it really
looks to be an error code (and I guess you really mean to log both).
Also please no unnecessary new uses of __func__.

> +}
> +if ( !ret )
> +{
> +ret = physdev_map_pirq(DOMID_SELF, MAP_PIRQ_TYPE_GSI, , ,
> +   NULL);
> +BUG_ON(ret);
> +
> +ret = pt_irq_bind_hw_domain(gsi);
> +BUG_ON(ret);

Why BUG_ON() (in both cases)? I don't think we're necessarily hosed
just because of one IRQ setup failure.

> @@ -409,7 +432,10 @@ void vioapic_update_EOI(struct domain *d, u8 vector)
>  if ( iommu_enabled )
>  {
>  spin_unlock(>arch.hvm_domain.irq_lock);
> -hvm_dpci_eoi(d, gsi, ent);
> +if ( is_hardware_domain(d) )
> +hvm_hw_dpci_eoi(d, gsi, ent);
> +else
> +hvm_dpci_eoi(d, gsi, ent);

This looks like you rather want to make the distinction inside the
called function.

> --- a/xen/drivers/passthrough/io.c
> +++ b/xen/drivers/passthrough/io.c
> @@ -159,26 +159,29 @@ static int pt_irq_guest_eoi(struct domain *d, struct 
> hvm_pirq_dpci *pirq_dpci,
>  static void pt_irq_time_out(void *data)
>  {
>  struct hvm_pirq_dpci *irq_map = data;
> -const struct hvm_irq_dpci *dpci;
>  const struct dev_intx_gsi_link *digl;
>  
>  spin_lock(_map->dom->event_lock);
>  
> -dpci = domain_get_irq_dpci(irq_map->dom);
> -ASSERT(dpci);
> -list_for_each_entry ( digl, _map->digl_list, list )
> +if ( !is_hardware_domain(irq_map->dom) )
>  {
> -unsigned int guest_gsi = hvm_pci_intx_gsi(digl->device, digl->intx);
> -const struct hvm_girq_dpci_mapping *girq;
> -
> -list_for_each_entry ( girq, >girq[guest_gsi], list )
> +const struct hvm_irq_dpci *dpci = domain_get_irq_dpci(irq_map->dom);
> +ASSERT(dpci);

Blank line between declarations and statements please.

> +list_for_each_entry ( digl, _map->digl_list, list )
>  {
> -struct pirq *pirq = pirq_info(irq_map->dom, girq->machine_gsi);
> +unsigned int guest_gsi = hvm_pci_intx_gsi(digl->device, 
> digl->intx);
> +const struct hvm_girq_dpci_mapping *girq;
> +
> +list_for_each_entry ( girq, >girq[guest_gsi], list )
> +{
> +struct pirq *pirq = pirq_info(irq_map->dom, 
> girq->machine_gsi);
>  
> -pirq_dpci(pirq)->flags |= HVM_IRQ_DPCI_EOI_LATCH;
> +pirq_dpci(pirq)->flags |= HVM_IRQ_DPCI_EOI_LATCH;
> +}
> +hvm_pci_intx_deassert(irq_map->dom, digl->device, digl->intx);
>  }
> -hvm_pci_intx_deassert(irq_map->dom, digl->device, digl->intx);
> -}
> +} else

Coding style.

> +irq_map->flags |= HVM_IRQ_DPCI_EOI_LATCH;

And I'm afraid I can't conclude anyway why you do what you do
here, as you don't really describe your the changes in any detail.

> @@ -557,6 +560,85 @@ int pt_irq_create_bind(
>  return 0;
>  }
>  
> +int pt_irq_bind_hw_domain(int gsi)
> +{
> +struct domain *d = hardware_domain;
> +struct hvm_pirq_dpci *pirq_dpci;
> +struct hvm_irq_dpci *hvm_irq_dpci;
> +struct pirq *info;
> +int rc;
> +
> +if ( gsi < 0 || gsi >= d->nr_pirqs )
> +return -EINVAL;
> +
> +restart:

Labels (if they're needed at all) indented by at least one blank
please.

And I'm afraid I'm giving up again.

Jan

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

Re: [Xen-devel] [PATCH v2 8/9] Config.mk: introduce cc-ifversion

2016-10-10 Thread Wei Liu

On Mon, Oct 10, 2016 at 07:22:57AM -0600, Jan Beulich wrote:
> >>> On 10.10.16 at 15:18,  wrote:
> > On Mon, Oct 10, 2016 at 06:00:03AM -0600, Jan Beulich wrote:
> >> >>> On 10.10.16 at 11:40,  wrote:
> >> > It returns different string depending on compiler version.
> >> > 
> >> > No user yet.
> >> > 
> >> > Signed-off-by: Wei Liu 
> >> 
> >> Acked-by: Jan Beulich 
> >> albeit I wonder whether ...
> >> 
> >> > --- a/Config.mk
> >> > +++ b/Config.mk
> >> > @@ -128,6 +128,11 @@ define cc-ver-check-closure
> >> >  endif
> >> >  endef
> >> >  
> >> > +# cc-ifversion: Check compiler version and take branch accordingly
> >> > +# Usage $(call cc-ifversion,lt,0x040700,string_if_y,string_if_n)
> >> > +cc-ifversion = $(shell [ $(call cc-ver,$(CC),$(1),$(2)) = "y" ] \
> >> > +&& echo $(3) || echo $(4))
> >> 
> >> ... if-cc-version wouldn't be the better name.
> > 
> > Linux uses cc-ifversion. That's the naming scheme I followed.
> 
> Oh, I didn't realize you've taken it from elsewhere.
> 

The name, yes. Implementation, no.

I thought we always tried to stay close to Linux naming though...

Wei.

> Jan
> 

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

Re: [Xen-devel] [PATCH v2 8/9] Config.mk: introduce cc-ifversion

2016-10-10 Thread Jan Beulich

>>> On 10.10.16 at 15:18,  wrote:
> On Mon, Oct 10, 2016 at 06:00:03AM -0600, Jan Beulich wrote:
>> >>> On 10.10.16 at 11:40,  wrote:
>> > It returns different string depending on compiler version.
>> > 
>> > No user yet.
>> > 
>> > Signed-off-by: Wei Liu 
>> 
>> Acked-by: Jan Beulich 
>> albeit I wonder whether ...
>> 
>> > --- a/Config.mk
>> > +++ b/Config.mk
>> > @@ -128,6 +128,11 @@ define cc-ver-check-closure
>> >  endif
>> >  endef
>> >  
>> > +# cc-ifversion: Check compiler version and take branch accordingly
>> > +# Usage $(call cc-ifversion,lt,0x040700,string_if_y,string_if_n)
>> > +cc-ifversion = $(shell [ $(call cc-ver,$(CC),$(1),$(2)) = "y" ] \
>> > +  && echo $(3) || echo $(4))
>> 
>> ... if-cc-version wouldn't be the better name.
> 
> Linux uses cc-ifversion. That's the naming scheme I followed.

Oh, I didn't realize you've taken it from elsewhere.

Jan


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

Re: [Xen-devel] [PATCH v2 8/9] Config.mk: introduce cc-ifversion

2016-10-10 Thread Wei Liu

On Mon, Oct 10, 2016 at 06:00:03AM -0600, Jan Beulich wrote:
> >>> On 10.10.16 at 11:40,  wrote:
> > It returns different string depending on compiler version.
> > 
> > No user yet.
> > 
> > Signed-off-by: Wei Liu 
> 
> Acked-by: Jan Beulich 
> albeit I wonder whether ...
> 
> > --- a/Config.mk
> > +++ b/Config.mk
> > @@ -128,6 +128,11 @@ define cc-ver-check-closure
> >  endif
> >  endef
> >  
> > +# cc-ifversion: Check compiler version and take branch accordingly
> > +# Usage $(call cc-ifversion,lt,0x040700,string_if_y,string_if_n)
> > +cc-ifversion = $(shell [ $(call cc-ver,$(CC),$(1),$(2)) = "y" ] \
> > +   && echo $(3) || echo $(4))
> 
> ... if-cc-version wouldn't be the better name.
> 

Linux uses cc-ifversion. That's the naming scheme I followed.

Wei.

> Jan
> 

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

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

2016-10-10 Thread osstest service owner

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

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  78ff18c905318a9b1e5dd32662986f03b10a4e56
baseline version:
 xen  84c1e7d8017c773c41d6e8b79384f37a67be1479

Last test of basis   101323  2016-10-07 10:01:01 Z3 days
Testing same since   101352  2016-10-10 11:01:28 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 

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=78ff18c905318a9b1e5dd32662986f03b10a4e56
+ . ./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 
78ff18c905318a9b1e5dd32662986f03b10a4e56
+ branch=xen-unstable-smoke
+ revision=78ff18c905318a9b1e5dd32662986f03b10a4e56
+ . ./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
+ '[' x78ff18c905318a9b1e5dd32662986f03b10a4e56 = 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
++ :

Re: [Xen-devel] [PATCH v2 5/9] gcov: add new interface and 3.4 and 4.7 format support

2016-10-10 Thread Wei Liu

On Mon, Oct 10, 2016 at 06:56:52AM -0600, Jan Beulich wrote:
> >>> On 10.10.16 at 14:23,  wrote:
> > On 10/10/16 12:56, Jan Beulich wrote:
> > On 10.10.16 at 11:40,  wrote:
> >>> +struct type_info {
> >>> +int ctr_type;
> >> Can this be negative?
> > 
> > This code is largely imported straight from Linux.  We should not
> > needlessly deviate.
> 
> Hmm, in that case some of the constification I did ask for on v1 and
> which is now there should also be undone? Perhaps for such a

I'm fine with either way. Since the modification is quite heavy, adding
some constification is just minor issue.

> purpose it would help if the original Linux files got first imported
> verbatim (without any review comments, and without getting wired
> up), in order to then be modified minimally to build/work on Xen?
> 

This would be ugly because the code used is only a small portion of what
Linux has (we would end up deleting most of the code -- memory
allocation, seqfile ops etc), and the modification to adapt it to Xen is
quite heavy because the interface is entirely different (procfs vs
hypercall, customised packed file).

Wei.

> Jan
> 

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

Re: [Xen-devel] [PATCH v2 5/9] gcov: add new interface and 3.4 and 4.7 format support

2016-10-10 Thread Wei Liu

On Mon, Oct 10, 2016 at 05:56:35AM -0600, Jan Beulich wrote:
[...]
> Who is 9 (more similar ones below)?
> 
> > +static int counter_active(const struct gcov_info *info, unsigned int type)
> > +{
> > +return info->merge[type] ? 1 : 0;
> 
> Return type bool and preferably with !! instead of conditional
> expression.
> 

Andrew beat me to it: the code and data structures above are mostly
imported from Linux.

> > +size_t gcov_store_u32(void *buffer, size_t off, u32 v)
> > +{
> > +u32 *data;
> 
> Please be consistent wrt u32 vs ...
> 
> > +static int gcov_info_dump_payload(const struct gcov_info *info,
> > +  XEN_GUEST_HANDLE_PARAM(char) buffer,
> > +  uint32_t *off)
> > +{
> > +char *buf;
> > +uint32_t buf_size;
> 
> ... uint32_t (and alike; I'd suggest using only the latter, and I think
> we should get rid of u32 / __u32 and their siblings eventually).
> 

Right. I will switch to using uint32_t.

> > +static uint32_t gcov_get_size(void)
> > +{
> > +uint32_t total_size;
> > +struct gcov_info *info = NULL;
> > +
> > +/* Magic number XCOV */
> > +total_size = sizeof(uint32_t);
> 
> Again - can't this be the initializer?
> 

Sure. I will move it up.

> > +int sysctl_gcov_op(xen_sysctl_gcov_op_t *op)
> > +{
> > +int ret;
> > +
> > +switch ( op->cmd )
> > +{
> > +case XEN_SYSCTL_GCOV_get_size:
> > +op->size = gcov_get_size();
> > +ret = 0;
> > +break;
> > +case XEN_SYSCTL_GCOV_read:
> 
> Blank lines between non-fall-through case statements please.
> 

OK.

> > --- /dev/null
> > +++ b/xen/common/gcov/gcov.h
> > @@ -0,0 +1,36 @@
> > +#ifndef _GCOV_H_
> > +#define _GCOV_H_
> > +
> > +#include 
> > +#include 
> > +
> > +/*
> > + * Profiling data types used for gcc 3.4 and above - these are defined by
> > + * gcc and need to be kept as close to the original definition as possible 
> > to
> > + * remain compatible.
> > + */
> > +#define GCOV_DATA_MAGIC ((unsigned int) 0x67636461)
> > +#define GCOV_TAG_FUNCTION   ((unsigned int) 0x0100)
> > +#define GCOV_TAG_COUNTER_BASE   ((unsigned int) 0x01a1)
> > +#define GCOV_TAG_FOR_COUNTER(count)\
> > +   _TAG_COUNTER_BASE + ((unsigned int) (count) << 17))
> 
> Stray blanks after casts.
> 

Will fix.

> > --- /dev/null
> > +++ b/xen/common/gcov/gcov_base.c
> > @@ -0,0 +1,64 @@
> > +/*
> > + * Common code across gcov implementations
> > + *
> > + * Copyright Citrix Systems R UK
> > + * Author(s): Wei Liu 
> > + *
> > + *Uses gcc-internal data definitions.
> > + *Based on the gcov-kernel patch by:
> > + *   Hubertus Franke 
> > + *   Nigel Hinds 
> > + *   Rajan Ravindran 
> > + *   Peter Oberparleiter 
> > + *   Paul Larson
> > + */
> > +
> > +#include "gcov.h"
> > +
> > +/*
> > + * __gcov_init is called by gcc-generated constructor code for each object
> > + * file compiled with -fprofile-arcs.
> > + *
> > + * Although this function is called only during initialization is called 
> > from
> > + * a .text section which is still present after initialization so not 
> > declare
> > + * as __init.
> 
> I don't follow - we do such references elsewhere, so I can't see a
> reason not to follow that model here too as long the call here
> happens before .init.* get discarded.
> 

This is residual from previous implementation. I haven't checked if the
statement is true or not. If this statement is not true I'm happy to
make corresponding adjustments.

> Having reached the end here - what if the user gets the Kconfig setting
> wrong? Wouldn't it be helpful if the gcov__.c files
> #error-ed upon an out of range gcc version?
> 

That's a good idea.

Wei.

> Jan

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

Re: [Xen-devel] [PATCH v2 5/9] gcov: add new interface and 3.4 and 4.7 format support

2016-10-10 Thread Jan Beulich

>>> On 10.10.16 at 14:23,  wrote:
> On 10/10/16 12:56, Jan Beulich wrote:
> On 10.10.16 at 11:40,  wrote:
>>> +struct type_info {
>>> +int ctr_type;
>> Can this be negative?
> 
> This code is largely imported straight from Linux.  We should not
> needlessly deviate.

Hmm, in that case some of the constification I did ask for on v1 and
which is now there should also be undone? Perhaps for such a
purpose it would help if the original Linux files got first imported
verbatim (without any review comments, and without getting wired
up), in order to then be modified minimally to build/work on Xen?

Jan

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

[Xen-devel] [PATCH for-4.8] ipxe: update to newer commit

2016-10-10 Thread Wei Liu

The current commit in tree is rather old. It has come to a point that
cherry-picking commits from upstream isn't trivial anymore.

There is long term plan to track ipxe upstream, but for 4.8 release, we
should just update ipxe to a newer commit (they are using rolling
release model now).

Forward-port the one boot prompt patch that is still relevant and retire
the rest which are already in upstream.

Reported-by: Juergen Schinker 
Signed-off-by: Wei Liu 
---
Cc: Ian Jackson 
Cc: Juergen Schinker 
---
 tools/firmware/etherboot/Makefile  |   2 +-
 .../etherboot/patches/boot_prompt_option.patch |  28 ++-
 .../firmware/etherboot/patches/build-compare.patch |  19 --
 tools/firmware/etherboot/patches/build_fix_1.patch |  28 ---
 tools/firmware/etherboot/patches/build_fix_2.patch |  48 -
 tools/firmware/etherboot/patches/build_fix_3.patch |  13 --
 tools/firmware/etherboot/patches/build_fix_4.patch | 225 -
 tools/firmware/etherboot/patches/series|   5 -
 8 files changed, 14 insertions(+), 354 deletions(-)
 delete mode 100644 tools/firmware/etherboot/patches/build-compare.patch
 delete mode 100644 tools/firmware/etherboot/patches/build_fix_1.patch
 delete mode 100644 tools/firmware/etherboot/patches/build_fix_2.patch
 delete mode 100644 tools/firmware/etherboot/patches/build_fix_3.patch
 delete mode 100644 tools/firmware/etherboot/patches/build_fix_4.patch

diff --git a/tools/firmware/etherboot/Makefile 
b/tools/firmware/etherboot/Makefile
index a0578d2..459a1e2 100644
--- a/tools/firmware/etherboot/Makefile
+++ b/tools/firmware/etherboot/Makefile
@@ -10,7 +10,7 @@ else
 IPXE_GIT_URL ?= git://git.ipxe.org/ipxe.git
 endif
 
-IPXE_GIT_TAG := 9a93db3f0947484e30e753bbd61a10b17336e20e
+IPXE_GIT_TAG := 827dd1bfee67daa683935ce65316f7e0f057fe1c
 
 IPXE_TARBALL_URL ?= $(XEN_EXTFILES_URL)/ipxe-git-$(IPXE_GIT_TAG).tar.gz
 
diff --git a/tools/firmware/etherboot/patches/boot_prompt_option.patch 
b/tools/firmware/etherboot/patches/boot_prompt_option.patch
index 25d72c5..aed0bf0 100644
--- a/tools/firmware/etherboot/patches/boot_prompt_option.patch
+++ b/tools/firmware/etherboot/patches/boot_prompt_option.patch
@@ -1,24 +1,22 @@
-diff --git a/src/arch/i386/prefix/romprefix.S 
b/src/arch/i386/prefix/romprefix.S
-index 0f92415..cce7505 100644
 a/src/arch/i386/prefix/romprefix.S
-+++ b/src/arch/i386/prefix/romprefix.S
-@@ -391,6 +391,7 @@ no_pmm:
-   xorw%di, %di
-   cs rep  movsb
- 
+--- a/src/arch/x86/prefix/romprefix.S  2016-10-10 13:09:18.126031400 +0100
 b/src/arch/x86/prefix/romprefix.S  2016-10-10 13:11:22.930680278 +0100
+@@ -468,6 +468,7 @@
+   testb   $PCI_FUNC_MASK, init_pci_busdevfn
+   jnz no_shell
+ .endif
 +#ifndef NO_POST_PROMPT
/* Prompt for POST-time shell */
movw$init_message_prompt, %si
xorw%di, %di
-@@ -418,6 +419,7 @@ no_pmm:
+@@ -495,6 +496,7 @@
pushw   %cs
callexec
- 2:
 +#endif
-   /* Restore registers */
-   popw%gs
-   popw%fs
-@@ -546,6 +548,7 @@ init_message_pmm:
+ no_shell:
+   movb$( '\n' ), %al
+   xorw%di, %di
+   callprint_character
+@@ -636,6 +638,7 @@
  init_message_int19:
.asciz  " INT19"
.size   init_message_int19, . - init_message_int19
@@ -26,7 +24,7 @@ index 0f92415..cce7505 100644
  init_message_prompt:
.asciz  "\nPress Ctrl-B to configure "
.size   init_message_prompt, . - init_message_prompt
-@@ -555,6 +558,7 @@ init_message_dots:
+@@ -645,6 +648,7 @@
  init_message_done:
.asciz  "\n\n"
.size   init_message_done, . - init_message_done
diff --git a/tools/firmware/etherboot/patches/build-compare.patch 
b/tools/firmware/etherboot/patches/build-compare.patch
deleted file mode 100644
index d41f68b..000
--- a/tools/firmware/etherboot/patches/build-compare.patch
+++ /dev/null
@@ -1,19 +0,0 @@
-The result of $(wildcard *) is random.
-Sort input files to reduce build-compare noise.

- ipxe/src/Makefile.housekeeping |2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-Index: ipxe/src/Makefile.housekeeping
-===
 ipxe/src/Makefile.housekeeping
-+++ ipxe/src/Makefile.housekeeping
-@@ -773,7 +773,7 @@ BLIB   = $(BIN)/blib.a
- $(BLIB) : $(BLIB_OBJS) $(BLIB_LIST) $(MAKEDEPS)
-   $(Q)$(RM) $(BLIB)
-   $(QM)$(ECHO) "  [AR] $@"
--  $(Q)$(AR) r $@ $(BLIB_OBJS)
-+  $(Q)$(AR) r $@ $(sort $(BLIB_OBJS))
-   $(Q)$(RANLIB) $@
- blib : $(BLIB)
- 
diff --git a/tools/firmware/etherboot/patches/build_fix_1.patch 
b/tools/firmware/etherboot/patches/build_fix_1.patch
deleted file mode 100644
index 9eacb9b..000
--- a/tools/firmware/etherboot/patches/build_fix_1.patch
+++ /dev/null
@@ -1,28 +0,0 @@
-Fix compile error in isabus_probe with gcc 4.7
-
-The copy of ipxe used

Re: [Xen-devel] [PATCH v2 20/30] xen/x86: add the basic infrastructure to import QEMU passthrough code

2016-10-10 Thread Jan Beulich

>>> On 27.09.16 at 17:57,  wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -632,6 +632,8 @@ int hvm_domain_initialise(struct domain *d)
>  goto fail1;
>  }
>  memset(d->arch.hvm_domain.io_bitmap, ~0, HVM_IOBITMAP_SIZE);
> +INIT_LIST_HEAD(>arch.hvm_domain.pt_devices);

This field appears to be redundant with arch.pdev_list.

> --- a/xen/arch/x86/hvm/io.c
> +++ b/xen/arch/x86/hvm/io.c
> @@ -46,6 +46,10 @@
>  #include 
>  #include 
>  
> +/* Set permissive mode for HVM Dom0 PCI pass-through by default */
> +static bool_t opt_dom0permissive = 1;

Plain bool / true / false please. And as mentioned by Andrew, we
should stop adding more dom0xyz options, and use a consolidated
dom0= one instead.

> @@ -258,12 +262,403 @@ static bool_t hw_dpci_portio_accept(const struct 
> hvm_io_handler *handler,
>  return 0;
>  }
>  
> +static struct hvm_pt_device *hw_dpci_get_device(struct domain *d)
> +{
> +uint8_t bus, slot, func;
> +uint32_t addr;
> +struct hvm_pt_device *dev;
> +
> +/* Decode bus, slot and func. */
> +addr = CF8_BDF(d->arch.pci_cf8);
> +bus = PCI_BUS(addr);
> +slot = PCI_SLOT(addr);
> +func = PCI_FUNC(addr);
> +
> +list_for_each_entry( dev, >arch.hvm_domain.pt_devices, entries )
> +{
> +if ( dev->pdev->seg != 0 || dev->pdev->bus != bus ||

Okay, there's no way segments other than 0 can be handled here.
But having glanced over the titles of the rest of the series - where
are those going to be handled (read: Where is the MCFG code,
which qemu doesn't have)?

Also I think the function name is not well chosen: Its prefix suggests
some kind of "official" interface, yet it really just is an internal helper
which doesn't even "get" a device in the general sense of needing to
"put" it later on.

And it looks like the parameter could be constified (but this appears
to be a wider problem).

> +/* Dispatchers */
> +
> +/* Find emulate register group entry */
> +struct hvm_pt_reg_group *hvm_pt_find_reg_grp(struct hvm_pt_device *d,
> + uint32_t address)

Please don't needlessly use fixed width types.

> +{
> +struct hvm_pt_reg_group *entry = NULL;
> +
> +/* Find register group entry */
> +list_for_each_entry( entry, >register_groups, entries )
> +{
> +/* check address */
> +if ( (entry->base_offset <= address)
> + && ((entry->base_offset + entry->size) > address) )

Coding style (&& belongs on the previous line).

And actually I guess I'll stop here, realizing that I'm completely
unconvinced of the not even spelled out intentions. Alone the
lifting of code from qemu is problematic imo: That code has proven
to have many issues, only the most severe of which have got fixed
over time. I'm therefore of the opinion that a clean re-write from
scratch should at least be considered, once it was written down
somewhere (docs/misc/hvmlite.markdown?) and agreed upon what
the behavior actually ought to be.

Jan

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

Re: [Xen-devel] [PATCH v2 5/9] gcov: add new interface and 3.4 and 4.7 format support

2016-10-10 Thread Andrew Cooper

On 10/10/16 12:56, Jan Beulich wrote:
 On 10.10.16 at 11:40,  wrote:
>> +struct type_info {
>> +int ctr_type;
> Can this be negative?

This code is largely imported straight from Linux.  We should not
needlessly deviate.

~Andrew

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

Re: [Xen-devel] [PATCH v7] xen/sm{e, a}p: allow disabling sm{e, a}p for Xen itself

2016-10-10 Thread Jan Beulich

>>> On 09.10.16 at 10:20,  wrote:
> Changes in v7:
> * bugfix: fix the bug that this patch doesn't work on machine without SMAP.
> * test: This patch has not been tested (on 32-bit PV environment).
> Really sorry for that since I have took several days trying to
> setup a 32-bit PV guest but finally failed.

Well, I don't know what to say. And since you don't say what your
problem is/was, I also don't see how anyone could help.

> @@ -1404,12 +1448,16 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>  
>  if ( !opt_smep )
>  setup_clear_cpu_cap(X86_FEATURE_SMEP);
> -if ( cpu_has_smep )
> +else if ( cpu_has_smep && opt_smep == 1 )

How about

if ( cpu_has_smep && opt_smep != SMEP_HVM_ONLY )

(i.e. I dislike both the "else" and the hard-coded 1)? Or if you dislike
this, then at least > 0 instead of == 1 please, or provide a #define
just like you do for -1.

Jan


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

Re: [Xen-devel] [PATCH v2 9/9] gcov: provide the capability to select gcov format automatically

2016-10-10 Thread Jan Beulich

>>> On 10.10.16 at 11:40,  wrote:
> And make it the default in Kconfig.
> 
> Signed-off-by: Wei Liu 

Acked-by: Jan Beulich 


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

Re: [Xen-devel] [PATCH v2 8/9] Config.mk: introduce cc-ifversion

2016-10-10 Thread Jan Beulich

>>> On 10.10.16 at 11:40,  wrote:
> It returns different string depending on compiler version.
> 
> No user yet.
> 
> Signed-off-by: Wei Liu 

Acked-by: Jan Beulich 
albeit I wonder whether ...

> --- a/Config.mk
> +++ b/Config.mk
> @@ -128,6 +128,11 @@ define cc-ver-check-closure
>  endif
>  endef
>  
> +# cc-ifversion: Check compiler version and take branch accordingly
> +# Usage $(call cc-ifversion,lt,0x040700,string_if_y,string_if_n)
> +cc-ifversion = $(shell [ $(call cc-ver,$(CC),$(1),$(2)) = "y" ] \
> + && echo $(3) || echo $(4))

... if-cc-version wouldn't be the better name.

Jan


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

Re: [Xen-devel] [PATCH v2 7/9] Config.mk: expand cc-ver a bit

2016-10-10 Thread Jan Beulich

>>> On 10.10.16 at 11:40,  wrote:
> ... so that we can do other comparisons as well.
> 
> No functional change.
> 
> Signed-off-by: Wei Liu 

Acked-by: Jan Beulich 


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

Re: [Xen-devel] [PATCH v2 5/9] gcov: add new interface and 3.4 and 4.7 format support

2016-10-10 Thread Jan Beulich

>>> On 10.10.16 at 11:40,  wrote:
> +struct type_info {
> +int ctr_type;

Can this be negative?

> +unsigned int offset;
> +};
> +
> +/**
> + * struct gcov_iterator - specifies current file position in logical records
> + * @info: associated profiling data
> + * @record: record type
> + * @function: function number
> + * @type: counter type
> + * @count: index into values array
> + * @num_types: number of counter types
> + * @type_info: helper array to get values-array offset for current function
> + */
> +struct gcov_iterator {
> +const struct gcov_info *info;
> +
> +int record;

This one indeed looks like it can be.

> +unsigned int function;
> +unsigned int type;
> +unsigned int count;
> +
> +int num_types;

But judging by its name, this surely can't be.

> +struct type_info type_info[GCOV_COUNTERS];
> +};
> +
> +/* Mapping of logical record number to actual file content. */
> +#define RECORD_FILE_MAGIC   0
> +#define RECORD_GCOV_VERSION 1
> +#define RECORD_TIME_STAMP   2
> +#define RECORD_FUNCTION_TAG 3
> +#define RECORD_FUNCTON_TAG_LEN  4
> +#define RECORD_FUNCTION_IDENT   5
> +#define RECORD_FUNCTION_CHECK   6
> +#define RECORD_COUNT_TAG7
> +#define RECORD_COUNT_LEN8
> +#define RECORD_COUNT9
> +
> +static int counter_active(const struct gcov_info *info, unsigned int type)
> +{
> +return (1 << type) & info->ctr_mask;

If the function return type is really meant to be a bitmask, then it
should be unsigned int (and 1u). However, I suspect this really
wants to be bool.

> +static size_t get_fn_size(const struct gcov_info *info)
> +{
> +size_t size;
> +
> +size = sizeof(struct gcov_fn_info) + num_counter_active(info) *
> +sizeof(unsigned int);

Any reason this is not the variable's initializer? Also please use
sizeof(*info) and alignof(*info) (below here).

> +static struct gcov_fn_info *get_fn_info(const struct gcov_info *info,
> +unsigned int fn)
> +{
> +return (struct gcov_fn_info *)
> +((char *) info->functions + fn * get_fn_size(info));

Stray blank after (char *) and sub-optimal indentation.

> +static int gcov_iter_next(struct gcov_iterator *iter)
> +{
> +switch ( iter->record )
> +{
> +case RECORD_FILE_MAGIC:
> +case RECORD_GCOV_VERSION:
> +case RECORD_FUNCTION_TAG:
> +case RECORD_FUNCTON_TAG_LEN:
> +case RECORD_FUNCTION_IDENT:
> +case RECORD_COUNT_TAG:
> +/* Advance to next record */
> +iter->record++;
> +break;
> +case RECORD_COUNT:
> +/* Advance to next count */
> +iter->count++;
> +/* fall through */
> +case RECORD_COUNT_LEN:
> +if ( iter->count < get_func(iter)->n_ctrs[iter->type] )
> +{
> +iter->record = 9;

Who is 9 (more similar ones below)?

> +static int counter_active(const struct gcov_info *info, unsigned int type)
> +{
> +return info->merge[type] ? 1 : 0;

Return type bool and preferably with !! instead of conditional
expression.

> +size_t gcov_store_u32(void *buffer, size_t off, u32 v)
> +{
> +u32 *data;

Please be consistent wrt u32 vs ...

> +static int gcov_info_dump_payload(const struct gcov_info *info,
> +  XEN_GUEST_HANDLE_PARAM(char) buffer,
> +  uint32_t *off)
> +{
> +char *buf;
> +uint32_t buf_size;

... uint32_t (and alike; I'd suggest using only the latter, and I think
we should get rid of u32 / __u32 and their siblings eventually).

> +static uint32_t gcov_get_size(void)
> +{
> +uint32_t total_size;
> +struct gcov_info *info = NULL;
> +
> +/* Magic number XCOV */
> +total_size = sizeof(uint32_t);

Again - can't this be the initializer?

> +int sysctl_gcov_op(xen_sysctl_gcov_op_t *op)
> +{
> +int ret;
> +
> +switch ( op->cmd )
> +{
> +case XEN_SYSCTL_GCOV_get_size:
> +op->size = gcov_get_size();
> +ret = 0;
> +break;
> +case XEN_SYSCTL_GCOV_read:

Blank lines between non-fall-through case statements please.

> --- /dev/null
> +++ b/xen/common/gcov/gcov.h
> @@ -0,0 +1,36 @@
> +#ifndef _GCOV_H_
> +#define _GCOV_H_
> +
> +#include 
> +#include 
> +
> +/*
> + * Profiling data types used for gcc 3.4 and above - these are defined by
> + * gcc and need to be kept as close to the original definition as possible 
> to
> + * remain compatible.
> + */
> +#define GCOV_DATA_MAGIC ((unsigned int) 0x67636461)
> +#define GCOV_TAG_FUNCTION   ((unsigned int) 0x0100)
> +#define GCOV_TAG_COUNTER_BASE   ((unsigned int) 0x01a1)
> +#define GCOV_TAG_FOR_COUNTER(count)  \
> + _TAG_COUNTER_BASE + ((unsigned int) (count) << 17))

Stray blanks after casts.

> --- /dev/null
> +++ b/xen/common/gcov/gcov_base.c
> @@ -0,0 +1,64 @@
> +/*
> + * Common code across gcov implementations
> + *
> + * Copyright Citrix Systems R UK
> + *

Re: [Xen-devel] [PATCH v2 4/9] xen, tools: rip out old gcov implementation

2016-10-10 Thread Jan Beulich

>>> On 10.10.16 at 11:40,  wrote:
> The internal data structure and code are tied to an old gcov format.
> It's easier to just redo everything from scratch.
> 
> Salvage the reusable parts: leave xen/common/gcov and an empty Makefile
> there, leave gcov support in Kconfig but mark that as broken. Also
> reserve the sysctl number for later use (but delete relevant sysctl
> structures).
> 
> Signed-off-by: Wei Liu 

Acked-by: Jan Beulich 


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

Re: [Xen-devel] [PATCH v2 3/9] xen: delete gcno files in clean target

2016-10-10 Thread Jan Beulich

>>> On 10.10.16 at 11:40,  wrote:
> Signed-off-by: Wei Liu 

Acked-by: Jan Beulich 


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

Re: [Xen-devel] [PATCH v2 1/9] Kconfig: use tab instead of space

2016-10-10 Thread Jan Beulich

>>> On 10.10.16 at 11:40,  wrote:
> Previously in d6be2cfc ("xen: make clear gcov support limitation in
> Kconfig") and db6c2264 ("xen: add a gcov Kconfig option"), space was
> used to indent Kconfig text. Change that to use tab instead.
> 
> No functional change.
> 
> Signed-off-by: Wei Liu 

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/9] Kconfig: add BROKEN config

2016-10-10 Thread Jan Beulich

>>> On 10.10.16 at 11:40,  wrote:
> Used to hide feature that is completely broken.
> 
> Signed-off-by: Wei Liu 

Reviewed-by: Jan Beulich 
(in case it matters for this trivial a patch)


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

[Xen-devel] [ovmf baseline-only test] 67855: regressions - FAIL

2016-10-10 Thread Platform Team regression test user

This run is configured for baseline tests only.

flight 67855 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67855/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ovmf-amd64  6 xen-boot  fail REGR. vs. 67853

version targeted for testing:
 ovmf cf8140930ab23497f729b1750b5962fe18dbc685
baseline version:
 ovmf 6859cc8b72d3c205853dd1030b143439f5b2215a

Last test of basis67853  2016-10-09 11:46:12 Z0 days
Testing same since67855  2016-10-10 07:48:15 Z0 days1 attempts


People who touched revisions under test:
  Cinnamon Shia 

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



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

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

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


Push not applicable.


commit cf8140930ab23497f729b1750b5962fe18dbc685
Author: Cinnamon Shia 
Date:   Mon Oct 3 17:28:30 2016 +0800

Nt32Pkg/PlatformBootManagerLib: Signal the End of DXE Event

From PI spec vol2:
Prior to invoking any UEFI drivers, applications, or connecting consoles,
the platform should signal the event EFI_END_OF_DXE_EVENT_GUID

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Cinnamon Shia 
Reviewed-by: Ruiyu Ni 

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

Re: [Xen-devel] [PATCH v2] x86/apicv: fix RTC periodic timer and apicv issue

2016-10-10 Thread Xuquan (Quan Xu)

On October 10, 2016 5:40 PM, Jan Beulich < jbeul...@suse.com > wrote:
>> >>> On 20.09.16 at 15:30,  wrote:
>> > --- a/xen/arch/x86/hvm/vlapic.c
>> > +++ b/xen/arch/x86/hvm/vlapic.c
>> > @@ -433,6 +433,12 @@ void vlapic_EOI_set(struct vlapic *vlapic)
>> > void vlapic_handle_EOI(struct vlapic *vlapic, u8 vector)  {
>> >  struct domain *d = vlapic_domain(vlapic);
>> > +struct vcpu *v = vlapic_vcpu(vlapic);
>> > +struct hvm_intack pt_intack;
>> > +
>> > +pt_intack.vector = vector;
>> > +pt_intack.source = hvm_intsrc_lapic;
>> > +pt_intr_post(v, pt_intack);
>>
>> This also sits on the EOI LAPIC register write path, i.e. the
>> change then also affects non-apicv environments.
>
>The new logic should be entered only when EOI-induced exit happens.
>

 Yes, more that the EOI-induced exit is conditional, specifically,
 the bitmap is set by vmx_set_eoi_exit_bitmap().
 Jan, what do you think? While I recall from v1 discussion, you have
 the same comment. We can dig it deep..
>>>
>>>See my reply to Kevin sent a minute ago. As I'm not sure what Kevin
>>>means to state with several of his responses, I can't properly respond
>>>for now. And then what you say doesn't really address my concern -
>>>things being conditional elsewhere doesn't mean we won't get here too
>>>in the non-apicv case, at least not in a way that I can follow right away.
>>
>> Jan, any idea now?
>
>I don't think there was anything left open on the other sub-thread; if there 
>is,
>please point out specific aspects which are still unclear.
>

Sorry, I overlooked the other sub-thread after holiday(10.1-10.7)..
I will read it again..

Quan

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

[Xen-devel] [PATCH v3] xenbus: advertize control feature flags

2016-10-10 Thread Paul Durrant

The Xen docs specify several flags which a guest can set to advertize
which values of the xenstore control/shutdown key it will recognize.
This patch adds code to write all the relevant feature-flag keys.

Signed-off-by: Paul Durrant 
Cc: Boris Ostrovsky 
Cc: David Vrabel 
Cc: Juergen Gross 
---

v2:
 - Fix flag logic inversion
 - Use kasprintf()

v3:
 - Re-instate check for flag mistakenly removed in v2
---
 drivers/xen/manage.c | 41 +++--
 1 file changed, 31 insertions(+), 10 deletions(-)

diff --git a/drivers/xen/manage.c b/drivers/xen/manage.c
index e12bd36..e16ba9f 100644
--- a/drivers/xen/manage.c
+++ b/drivers/xen/manage.c
@@ -170,6 +170,7 @@ out:
 struct shutdown_handler {
const char *command;
void (*cb)(void);
+   bool flag;
 };
 
 static int poweroff_nb(struct notifier_block *cb, unsigned long code, void 
*unused)
@@ -206,21 +207,22 @@ static void do_reboot(void)
ctrl_alt_del();
 }
 
+static struct shutdown_handler shutdown_handlers[] = {
+   { "poweroff", do_poweroff, true },
+   { "halt", do_poweroff, false },
+   { "reboot", do_reboot, true },
+#ifdef CONFIG_HIBERNATE_CALLBACKS
+   { "suspend", do_suspend, true },
+#endif
+   {NULL, NULL, false },
+};
+
 static void shutdown_handler(struct xenbus_watch *watch,
 const char **vec, unsigned int len)
 {
char *str;
struct xenbus_transaction xbt;
int err;
-   static struct shutdown_handler handlers[] = {
-   { "poweroff",   do_poweroff },
-   { "halt",   do_poweroff },
-   { "reboot", do_reboot   },
-#ifdef CONFIG_HIBERNATE_CALLBACKS
-   { "suspend",do_suspend  },
-#endif
-   {NULL, NULL},
-   };
static struct shutdown_handler *handler;
 
if (shutting_down != SHUTDOWN_INVALID)
@@ -238,7 +240,7 @@ static void shutdown_handler(struct xenbus_watch *watch,
return;
}
 
-   for (handler = [0]; handler->command; handler++) {
+   for (handler = _handlers[0]; handler->command; handler++) {
if (strcmp(str, handler->command) == 0)
break;
}
@@ -309,8 +311,27 @@ static struct notifier_block xen_reboot_nb = {
 
 static int setup_shutdown_watcher(void)
 {
+   static struct shutdown_handler *handler;
int err;
 
+   for (handler = _handlers[0]; handler->command; handler++) {
+   char *node;
+
+   if (!handler->flag)
+   continue;
+
+   node = kasprintf(GFP_KERNEL, "feature-%s",
+handler->command);
+   if (!node) {
+   pr_err("Failed to allocate feature flag\n");
+   return -ENOMEM;
+   }
+
+   xenbus_printf(XBT_NIL, "control", node, "%u", 1);
+
+   kfree(node);
+   }
+
err = register_xenbus_watch(_watch);
if (err) {
pr_err("Failed to set shutdown watcher\n");
-- 
2.1.4


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

Re: [Xen-devel] [RFC PATCH 12/24] ARM: vGICv3: introduce basic ITS emulation bits

2016-10-10 Thread Andre Przywara

Hi,

On 09/10/16 15:20, Vijay Kilari wrote:
> On Wed, Sep 28, 2016 at 11:54 PM, Andre Przywara  
> wrote:
>> Create a new file to hold the emulation code for the ITS widget.
>> For now we emulate the memory mapped ITS registers and provide a stub
>> to introduce the ITS command handling framework (but without actually
>> emulating any commands at this time).
>>
>> Signed-off-by: Andre Przywara 
>> ---
>>  xen/arch/arm/Makefile |   1 +
>>  xen/arch/arm/vgic-its.c   | 378 
>> ++
>>  xen/arch/arm/vgic-v3.c|   9 -
>>  xen/include/asm-arm/gic_v3_defs.h |  19 ++
>>  4 files changed, 398 insertions(+), 9 deletions(-)
>>  create mode 100644 xen/arch/arm/vgic-its.c
>>
>> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
>> index c2c4daa..cb0201f 100644
>> --- a/xen/arch/arm/Makefile
>> +++ b/xen/arch/arm/Makefile
>> @@ -44,6 +44,7 @@ obj-y += traps.o
>>  obj-y += vgic.o
>>  obj-y += vgic-v2.o
>>  obj-$(CONFIG_ARM_64) += vgic-v3.o
>> +obj-$(CONFIG_HAS_ITS) += vgic-its.o
>>  obj-y += vm_event.o
>>  obj-y += vtimer.o
>>  obj-y += vpsci.o
>> diff --git a/xen/arch/arm/vgic-its.c b/xen/arch/arm/vgic-its.c
>> new file mode 100644
>> index 000..875b992
>> --- /dev/null
>> +++ b/xen/arch/arm/vgic-its.c
>> @@ -0,0 +1,378 @@
>> +/*
>> + * xen/arch/arm/vgic-its.c
>> + *
>> + * ARM Interrupt Translation Service (ITS) emulation
>> + *
>> + * Andre Przywara 
>> + * Copyright (c) 2016 ARM Ltd.
>> + *
>> + * 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.
>> + *
>> + * 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 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +/* Data structure to describe a virtual ITS */
>> +struct virt_its {
>> +struct domain *d;
>> +struct host_its *hw_its;
>> +spinlock_t vcmd_lock;   /* protects the virtual command buffer */
>> +uint64_t cbaser;
>> +uint64_t *cmdbuf;
>> +int cwriter;
>> +int creadr;
>> +spinlock_t its_lock;/* protects the collection and device 
>> tables */
>> +uint64_t baser0, baser1;
>> +uint16_t *coll_table;
>> +int max_collections;
>> +uint64_t *dev_table;
>> +int max_devices;
>> +bool enabled;
>> +};
>> +
>> +/* An Interrupt Translation Table Entry: this is indexed by a
>> + * DeviceID/EventID pair and is located in guest memory.
>> + */
>> +struct vits_itte
>> +{
>> +uint64_t hlpi:24;
>> +uint64_t vlpi:24;
>> +uint64_t collection:16;
>> +};
>> +
>> +/**
>> + * Functions that handle ITS commands *
>> + **/
>> +
>> +static uint64_t its_cmd_mask_field(uint64_t *its_cmd,
>> +   int word, int shift, int size)
>> +{
>> +return (le64_to_cpu(its_cmd[word]) >> shift) & (BIT(size) - 1);
>> +}
>> +
>> +#define its_cmd_get_command(cmd)its_cmd_mask_field(cmd, 0,  0,  8)
>> +#define its_cmd_get_deviceid(cmd)   its_cmd_mask_field(cmd, 0, 32, 32)
>> +#define its_cmd_get_size(cmd)   its_cmd_mask_field(cmd, 1,  0,  5)
>> +#define its_cmd_get_id(cmd) its_cmd_mask_field(cmd, 1,  0, 32)
>> +#define its_cmd_get_physical_id(cmd)its_cmd_mask_field(cmd, 1, 32, 32)
>> +#define its_cmd_get_collection(cmd) its_cmd_mask_field(cmd, 2,  0, 16)
>> +#define its_cmd_get_target_addr(cmd)its_cmd_mask_field(cmd, 2, 16, 32)
>> +#define its_cmd_get_validbit(cmd)   its_cmd_mask_field(cmd, 2, 63,  1)
>> +
>> +#define ITS_CMD_BUFFER_SIZE(baser)  baser) & 0xff) + 1) << 12)
>> +
>> +static int vgic_its_handle_cmds(struct domain *d, struct virt_its *its,
>> +uint32_t writer)
>> +{
>> +uint64_t *cmdptr;
>> +
>> +if ( !its->cmdbuf )
>> +return -1;
>> +
>> +if ( writer >= ITS_CMD_BUFFER_SIZE(its->cbaser) )
>> +return -1;
>> +
>> +spin_lock(>vcmd_lock);
>> +
>> +while ( its->creadr != writer )
>> +{
>> +cmdptr = its->cmdbuf + (its->creadr / sizeof(*its->cmdbuf));
>> +switch (its_cmd_get_command(cmdptr))
>> +{
>> +case GITS_CMD_SYNC:
>> +/* We handle ITS commands synchronously, so we ignore SYNC. */
>> +   break;
>> +default:
>> +gdprintk(XENLOG_G_WARNING, "ITS: unhandled ITS command %ld\n",
>> +

Re: [Xen-devel] [PATCH v2] xenbus: advertize control feature flags

2016-10-10 Thread Paul Durrant

> -Original Message-
> From: David Vrabel [mailto:david.vra...@citrix.com]
> Sent: 10 October 2016 11:16
> To: Paul Durrant ; linux-ker...@vger.kernel.org;
> xen-de...@lists.xenproject.org
> Cc: Boris Ostrovsky ; Juergen Gross
> 
> Subject: Re: [PATCH v2] xenbus: advertize control feature flags
> 
> On 10/10/16 10:43, Paul Durrant wrote:
> > The Xen docs specify several flags which a guest can set to advertize
> > which values of the xenstore control/shutdown key it will recognize.
> > This patch adds code to write all the relevant feature-flag keys.
> [...]
> >  static int setup_shutdown_watcher(void)
> >  {
> > +   static struct shutdown_handler *handler;
> > int err;
> >
> > +   for (handler = _handlers[0]; handler->command;
> handler++) {
> > +   char *node;
> 
> char node[20];

I didn't want to pick arbitrary numbers. I'd prefer to stick with kasprintf().

  Paul

> 
> and avoid the allocation and resulting error path.
> 
> As Juergen notes, the 'flag' field isn't used anywhere now.  Can you
> please test your patches and verify the correct keys are being created?
> 
> David

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

Re: [Xen-devel] [PATCH v2] xenbus: advertize control feature flags

2016-10-10 Thread David Vrabel

On 10/10/16 10:43, Paul Durrant wrote:
> The Xen docs specify several flags which a guest can set to advertize
> which values of the xenstore control/shutdown key it will recognize.
> This patch adds code to write all the relevant feature-flag keys.
[...]
>  static int setup_shutdown_watcher(void)
>  {
> + static struct shutdown_handler *handler;
>   int err;
>  
> + for (handler = _handlers[0]; handler->command; handler++) {
> + char *node;

char node[20];

and avoid the allocation and resulting error path.

As Juergen notes, the 'flag' field isn't used anywhere now.  Can you
please test your patches and verify the correct keys are being created?

David

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

[Xen-devel] [distros-debian-sid test] 67854: tolerable FAIL

2016-10-10 Thread Platform Team regression test user

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-armhf-sid-netboot-pygrub 9 debian-di-install fail blocked in 
67789
 test-amd64-i386-i386-sid-netboot-pvgrub  9 debian-di-install   fail like 67789
 test-amd64-i386-amd64-sid-netboot-pygrub  9 debian-di-install  fail like 67789
 test-amd64-amd64-i386-sid-netboot-pygrub  9 debian-di-install  fail like 67789
 test-amd64-amd64-amd64-sid-netboot-pvgrub  9 debian-di-install fail like 67789

baseline version:
 flight   67789

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-sid-netboot-pvgrubfail
 test-amd64-i386-i386-sid-netboot-pvgrub  fail
 test-amd64-i386-amd64-sid-netboot-pygrub fail
 test-armhf-armhf-armhf-sid-netboot-pygrubfail
 test-amd64-amd64-i386-sid-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] xenbus: advertize control feature flags

2016-10-10 Thread Juergen Gross

On 10/10/16 11:43, Paul Durrant wrote:
> The Xen docs specify several flags which a guest can set to advertize
> which values of the xenstore control/shutdown key it will recognize.
> This patch adds code to write all the relevant feature-flag keys.
> 
> Signed-off-by: Paul Durrant 
> Cc: Boris Ostrovsky 
> Cc: David Vrabel 
> Cc: Juergen Gross 
> ---
> 
> v2:
>  - Fix flag logic inversion
>  - Use kasprintf()
> ---
>  drivers/xen/manage.c | 38 --
>  1 file changed, 28 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/xen/manage.c b/drivers/xen/manage.c
> index e12bd36..0671b98 100644
> --- a/drivers/xen/manage.c
> +++ b/drivers/xen/manage.c
> @@ -170,6 +170,7 @@ out:
>  struct shutdown_handler {
>   const char *command;
>   void (*cb)(void);
> + bool flag;
>  };
>  
>  static int poweroff_nb(struct notifier_block *cb, unsigned long code, void 
> *unused)
> @@ -206,21 +207,22 @@ static void do_reboot(void)
>   ctrl_alt_del();
>  }
>  
> +static struct shutdown_handler shutdown_handlers[] = {
> + { "poweroff", do_poweroff, true },
> + { "halt", do_poweroff, false },
> + { "reboot", do_reboot, true },
> +#ifdef CONFIG_HIBERNATE_CALLBACKS
> + { "suspend", do_suspend, true },
> +#endif
> + {NULL, NULL, false },
> +};
> +
>  static void shutdown_handler(struct xenbus_watch *watch,
>const char **vec, unsigned int len)
>  {
>   char *str;
>   struct xenbus_transaction xbt;
>   int err;
> - static struct shutdown_handler handlers[] = {
> - { "poweroff",   do_poweroff },
> - { "halt",   do_poweroff },
> - { "reboot", do_reboot   },
> -#ifdef CONFIG_HIBERNATE_CALLBACKS
> - { "suspend",do_suspend  },
> -#endif
> - {NULL, NULL},
> - };
>   static struct shutdown_handler *handler;
>  
>   if (shutting_down != SHUTDOWN_INVALID)
> @@ -238,7 +240,7 @@ static void shutdown_handler(struct xenbus_watch *watch,
>   return;
>   }
>  
> - for (handler = [0]; handler->command; handler++) {
> + for (handler = _handlers[0]; handler->command; handler++) {
>   if (strcmp(str, handler->command) == 0)
>   break;
>   }
> @@ -309,8 +311,24 @@ static struct notifier_block xen_reboot_nb = {
>  
>  static int setup_shutdown_watcher(void)
>  {
> + static struct shutdown_handler *handler;
>   int err;
>  
> + for (handler = _handlers[0]; handler->command; handler++) {
> + char *node;
> +
> + node = kasprintf(GFP_KERNEL, "feature-%s",
> +  handler->command);

Now you've dropped using flag?


Juergen

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

Re: [Xen-devel] per-domain logging

2016-10-10 Thread Wei Liu

On Mon, Oct 10, 2016 at 09:03:49AM +0200, Cedric Bosdonnat wrote:
> On Fri, 2016-10-07 at 15:09 +0100, Wei Liu wrote:
> > Instead of trying to change all the format strings I think it would be
> > better to have a new set of LOG macros that takes domid.
> > 
> > Something like:
> >   LOGEVD(ERROR, errno, domid, "");
> 
> Sounds good to me, even if LOGEVD will just concatenate something like
> "Domain %d: " to the "". At least this would be much cleaner in the
> libxl code
> 
> > I would also like to have the log format written down in some document
> > or header file.
> 
> You mean as a documentation? That would be in libxl, not in xtl, right?
> We could have a comment above the LOG*D macros explaining what the message
> will look like (Prepending 'Domain %d: " to the message passed to normal log
> functions). And a comment on top of the current functions explaining all the
> different things that are passed on to xtl.
> 

Presumably you will define LOG*D variants in libxl_internal.h, I think a
comment there right before those macros will be good enough.

> > But let's step back a bit: have we agreed on the approach forward? This
> > thread doesn't seem to have a clear conclusion yet.  Obviously I don't
> > want you to waste your writing code that's going to be threw away.
> 
> I don't want to loose time either, but sometimes it's better to write some
> code to check that what we are mentioning is possible.
> 
> > If you're happy with demuxing in libvirt, I won't object to it. Looks
> > like there is relatively less code churn involved than other solutions,
> > say, libxl keeping track of a set of per-domain xtl loggers.
> 
> Having a set of per-domain xtl logger is also possible, but with one logger
> demuxing all messages, it's fairly easy to support both old log format
> and new ones. And the format we get in the callbacks from libxl is something
> like "%s%s%s%s%s", with things like file, line, function and message. Thus
> adding a domain in there doesn't make much sense. I'ld more in favor of the
> LOG*D family in libxl.
> 

Sure, fine by me.

Wei.

> --
> Cedric

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

Re: [Xen-devel] [PATCH v2] x86: defer not-present segment checks

2016-10-10 Thread Andrew Cooper

On 10/10/16 11:04, Jan Beulich wrote:
> Following on from commits 5602e74c60 ("x86emul: correct loading of
> %ss") and bdb860d01c ("x86/HVM: correct segment register loading during
> task switch") the point of the non-.present checks needs to be refined:
> #NP (and its #SS companion), other than suggested by the various
> instruction pages in Intel's SDM, gets checked for only after all type
> and permission checks. The only checks getting done even later are the
> long mode specific ones for system descriptors (which we don't support
> yet) and 64-bit code segments (i.e. anything touching other than the
> attribute byte).
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

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

[Xen-devel] [PATCH v2] x86: defer not-present segment checks

2016-10-10 Thread Jan Beulich

Following on from commits 5602e74c60 ("x86emul: correct loading of
%ss") and bdb860d01c ("x86/HVM: correct segment register loading during
task switch") the point of the non-.present checks needs to be refined:
#NP (and its #SS companion), other than suggested by the various
instruction pages in Intel's SDM, gets checked for only after all type
and permission checks. The only checks getting done even later are the
long mode specific ones for system descriptors (which we don't support
yet) and 64-bit code segments (i.e. anything touching other than the
attribute byte).

Signed-off-by: Jan Beulich 
---
v2: Defer L/D bits check on 64-bit code segments until after the P bit
one.

--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2754,14 +2754,6 @@ static int hvm_load_segment_selector(
 do {
 desc = *pdesc;
 
-/* Segment present in memory? */
-if ( !(desc.b & _SEGMENT_P) )
-{
-fault_type = (seg != x86_seg_ss) ? TRAP_no_segment
- : TRAP_stack_error;
-goto unmap_and_fail;
-}
-
 /* LDT descriptor is a system segment. All others are code/data. */
 if ( (desc.b & (1u<<12)) == ((seg == x86_seg_ldtr) << 12) )
 goto unmap_and_fail;
@@ -2806,6 +2798,14 @@ static int hvm_load_segment_selector(
 goto unmap_and_fail;
 break;
 }
+
+/* Segment present in memory? */
+if ( !(desc.b & _SEGMENT_P) )
+{
+fault_type = (seg != x86_seg_ss) ? TRAP_no_segment
+ : TRAP_stack_error;
+goto unmap_and_fail;
+}
 } while ( !(desc.b & 0x100) && /* Ensure Accessed flag is set */
   writable && /* except if we are to discard writes */
   (cmpxchg(>b, desc.b, desc.b | 0x100) != desc.b) );
@@ -2892,12 +2892,6 @@ void hvm_task_switch(
 if ( tr.attr.fields.g )
 tr.limit = (tr.limit << 12) | 0xfffu;
 
-if ( !tr.attr.fields.p )
-{
-hvm_inject_hw_exception(TRAP_no_segment, tss_sel & 0xfff8);
-goto out;
-}
-
 if ( tr.attr.fields.type != ((taskswitch_reason == TSW_iret) ? 0xb : 0x9) )
 {
 hvm_inject_hw_exception(
@@ -2906,6 +2900,12 @@ void hvm_task_switch(
 goto out;
 }
 
+if ( !tr.attr.fields.p )
+{
+hvm_inject_hw_exception(TRAP_no_segment, tss_sel & 0xfff8);
+goto out;
+}
+
 if ( tr.limit < (sizeof(tss)-1) )
 {
 hvm_inject_hw_exception(TRAP_invalid_tss, tss_sel & 0xfff8);
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1311,7 +1311,7 @@ protmode_load_seg(
 struct { uint32_t a, b; } desc;
 uint8_t dpl, rpl;
 int cpl = get_cpl(ctxt, ops);
-uint32_t new_desc_b, a_flag = 0x100;
+uint32_t a_flag = 0x100;
 int rc, fault_type = EXC_GP;
 
 if ( cpl < 0 )
@@ -1352,13 +1352,6 @@ protmode_load_seg(
  , sizeof(desc), ctxt)) )
 return rc;
 
-/* Segment present in memory? */
-if ( !(desc.b & (1u<<15)) )
-{
-fault_type = seg != x86_seg_ss ? EXC_NP : EXC_SS;
-goto raise_exn;
-}
-
 if ( !is_x86_user_segment(seg) )
 {
 /* System segments must have S flag == 0. */
@@ -1393,10 +1386,6 @@ protmode_load_seg(
/* Non-conforming segment: check RPL and DPL against CPL. */
: rpl > cpl || dpl != cpl )
 goto raise_exn;
-/* 64-bit code segments (L bit set) must have D bit clear. */
-if ( in_longmode(ctxt, ops) &&
- (desc.b & (1 << 21)) && (desc.b & (1 << 22)) )
-goto raise_exn;
 sel = (sel ^ rpl) | cpl;
 break;
 case x86_seg_ss:
@@ -1410,7 +1399,8 @@ protmode_load_seg(
 /* LDT system segment? */
 if ( (desc.b & (15u<<8)) != (2u<<8) )
 goto raise_exn;
-goto skip_accessed_flag;
+a_flag = 0;
+break;
 case x86_seg_tr:
 /* Available TSS system segment? */
 if ( (desc.b & (15u<<8)) != (9u<<8) )
@@ -1428,18 +1418,31 @@ protmode_load_seg(
 break;
 }
 
+/* Segment present in memory? */
+if ( !(desc.b & (1 << 15)) )
+{
+fault_type = seg != x86_seg_ss ? EXC_NP : EXC_SS;
+goto raise_exn;
+}
+
+/* 64-bit code segments (L bit set) must have D bit clear. */
+if ( seg == x86_seg_cs && in_longmode(ctxt, ops) &&
+ (desc.b & (1 << 21)) && (desc.b & (1 << 22)) )
+goto raise_exn;
+
 /* Ensure Accessed flag is set. */
-new_desc_b = desc.b | a_flag;
-if ( !(desc.b & a_flag) &&
- ((rc = ops->cmpxchg(
- x86_seg_none, desctab.base + (sel & 0xfff8) + 4,
- , _desc_b, 4, ctxt)) != 0) )
-return rc;
+if ( a_flag && !(desc.b & a_flag) )
+{
+uint32_t new_desc_b = desc.b | a_flag;
 
-/* Force the Accessed

[Xen-devel] [PATCH v2] xenbus: advertize control feature flags

2016-10-10 Thread Paul Durrant

The Xen docs specify several flags which a guest can set to advertize
which values of the xenstore control/shutdown key it will recognize.
This patch adds code to write all the relevant feature-flag keys.

Signed-off-by: Paul Durrant 
Cc: Boris Ostrovsky 
Cc: David Vrabel 
Cc: Juergen Gross 
---

v2:
 - Fix flag logic inversion
 - Use kasprintf()
---
 drivers/xen/manage.c | 38 --
 1 file changed, 28 insertions(+), 10 deletions(-)

diff --git a/drivers/xen/manage.c b/drivers/xen/manage.c
index e12bd36..0671b98 100644
--- a/drivers/xen/manage.c
+++ b/drivers/xen/manage.c
@@ -170,6 +170,7 @@ out:
 struct shutdown_handler {
const char *command;
void (*cb)(void);
+   bool flag;
 };
 
 static int poweroff_nb(struct notifier_block *cb, unsigned long code, void 
*unused)
@@ -206,21 +207,22 @@ static void do_reboot(void)
ctrl_alt_del();
 }
 
+static struct shutdown_handler shutdown_handlers[] = {
+   { "poweroff", do_poweroff, true },
+   { "halt", do_poweroff, false },
+   { "reboot", do_reboot, true },
+#ifdef CONFIG_HIBERNATE_CALLBACKS
+   { "suspend", do_suspend, true },
+#endif
+   {NULL, NULL, false },
+};
+
 static void shutdown_handler(struct xenbus_watch *watch,
 const char **vec, unsigned int len)
 {
char *str;
struct xenbus_transaction xbt;
int err;
-   static struct shutdown_handler handlers[] = {
-   { "poweroff",   do_poweroff },
-   { "halt",   do_poweroff },
-   { "reboot", do_reboot   },
-#ifdef CONFIG_HIBERNATE_CALLBACKS
-   { "suspend",do_suspend  },
-#endif
-   {NULL, NULL},
-   };
static struct shutdown_handler *handler;
 
if (shutting_down != SHUTDOWN_INVALID)
@@ -238,7 +240,7 @@ static void shutdown_handler(struct xenbus_watch *watch,
return;
}
 
-   for (handler = [0]; handler->command; handler++) {
+   for (handler = _handlers[0]; handler->command; handler++) {
if (strcmp(str, handler->command) == 0)
break;
}
@@ -309,8 +311,24 @@ static struct notifier_block xen_reboot_nb = {
 
 static int setup_shutdown_watcher(void)
 {
+   static struct shutdown_handler *handler;
int err;
 
+   for (handler = _handlers[0]; handler->command; handler++) {
+   char *node;
+
+   node = kasprintf(GFP_KERNEL, "feature-%s",
+handler->command);
+   if (!node) {
+   pr_err("Failed to allocate feature flag\n");
+   return -ENOMEM;
+   }
+
+   xenbus_printf(XBT_NIL, "control", node, "%u", 1);
+
+   kfree(node);
+   }
+
err = register_xenbus_watch(_watch);
if (err) {
pr_err("Failed to set shutdown watcher\n");
-- 
2.1.4


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

Re: [Xen-devel] [BUG] Re: testing XEN-4.8-rc1

2016-10-10 Thread Wei Liu

On Mon, Oct 10, 2016 at 10:36:04AM +0100, Juergen Schinker wrote:
> Ok then on Debian testing 
> 
>  ii  gcc-6 6.2.0-5
>   amd64GNU C compiler
> 

Right, I think I know why it didn't build for you.

We've got some medium to long term plan for it, but for this release we
need something to fix it as quick as we can.

Let me try to write a patch.

Wei.

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

[Xen-devel] [xen-unstable test] 101347: tolerable FAIL

2016-10-10 Thread osstest service owner

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-credit2  16 guest-start.2  fail pass in 101339

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail  like 101324
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 101339
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 101339
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101339
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101339
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 101339

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

version targeted for testing:
 xen  84c1e7d8017c773c41d6e8b79384f37a67be1479
baseline version:
 xen  84c1e7d8017c773c41d6e8b79384f37a67be1479

Last test of basis   101347  2016-10-10 02:00:16 Z0 days
Testing same since0  1970-01-01 00:00:00 Z 17084 days0 attempts

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64-xtf  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

Re: [Xen-devel] [PATCH net] xen-netback: (re-)create a debugfs node for hash information

2016-10-10 Thread Wei Liu

On Mon, Oct 10, 2016 at 09:30:53AM +0100, Paul Durrant wrote:
> From: Paul Durrant 
> 
> It is useful to be able to see the hash configuration when running tests.
> This patch adds a debugfs node for that purpose.
> 
> The original version of this patch (commit c0c64c152389) was reverted due
> to build failures caused by a conflict with commit 0364a8824c02
> ("xen-netback: switch to threaded irq for control ring"). This new version
> of the patch is nearly identical to the original, the only difference
> being that creation of the debugfs node is predicated on 'ctrl_irq' being
> non-zero rather then the now non-existent 'ctrl_task'.
> 
> Signed-off-by: Paul Durrant 
> Cc: Wei Liu 
> Cc: David S. Miller 

Acked-by: Wei Liu 

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

[Xen-devel] [PATCH v2 8/9] Config.mk: introduce cc-ifversion

2016-10-10 Thread Wei Liu

It returns different string depending on compiler version.

No user yet.

Signed-off-by: Wei Liu 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
 Config.mk | 5 +
 1 file changed, 5 insertions(+)

diff --git a/Config.mk b/Config.mk
index af50137..844be0a 100644
--- a/Config.mk
+++ b/Config.mk
@@ -128,6 +128,11 @@ define cc-ver-check-closure
 endif
 endef
 
+# cc-ifversion: Check compiler version and take branch accordingly
+# Usage $(call cc-ifversion,lt,0x040700,string_if_y,string_if_n)
+cc-ifversion = $(shell [ $(call cc-ver,$(CC),$(1),$(2)) = "y" ] \
+   && echo $(3) || echo $(4))
+
 # Require GCC v4.1+
 check-$(gcc) = $(call cc-ver-check,CC,0x040100,"Xen requires at least gcc-4.1")
 $(eval $(check-y))
-- 
2.1.4


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

[Xen-devel] [PATCH v2 1/9] Kconfig: use tab instead of space

2016-10-10 Thread Wei Liu

Previously in d6be2cfc ("xen: make clear gcov support limitation in
Kconfig") and db6c2264 ("xen: add a gcov Kconfig option"), space was
used to indent Kconfig text. Change that to use tab instead.

No functional change.

Signed-off-by: Wei Liu 
---

v2: new

Would like to have this in 4.8

Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
 xen/Kconfig.debug | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
index 12a1193..e9f7dcd 100644
--- a/xen/Kconfig.debug
+++ b/xen/Kconfig.debug
@@ -29,15 +29,15 @@ config FRAME_POINTER
  in case of any Xen bugs.
 
 config GCOV
-   bool "Gcov Support"
-   ---help---
- Enable gcov (a test coverage program in GCC) support.
+   bool "Gcov Support"
+   ---help---
+ Enable gcov (a test coverage program in GCC) support.
 
- Currently the data structure and hypercall interface are tied
- to GCC 3.4 gcov format. You need to have a version of GCC
- that is compatible with that format to make gcov work.
+ Currently the data structure and hypercall interface are tied
+ to GCC 3.4 gcov format. You need to have a version of GCC
+ that is compatible with that format to make gcov work.
 
- If unsure, say N here.
+ If unsure, say N here.
 
 config LOCK_PROFILE
bool "Lock Profiling"
-- 
2.1.4


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

[Xen-devel] [PATCH v2 4/9] xen, tools: rip out old gcov implementation

2016-10-10 Thread Wei Liu

The internal data structure and code are tied to an old gcov format.
It's easier to just redo everything from scratch.

Salvage the reusable parts: leave xen/common/gcov and an empty Makefile
there, leave gcov support in Kconfig but mark that as broken. Also
reserve the sysctl number for later use (but delete relevant sysctl
structures).

Signed-off-by: Wei Liu 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
 tools/misc/Makefile |   6 --
 tools/misc/xencov.c | 147 -
 tools/misc/xencov_split | 188 
 xen/Kconfig.debug   |   1 +
 xen/common/gcov/Makefile|   2 -
 xen/common/gcov/gcov.c  | 225 
 xen/common/sysctl.c |   7 --
 xen/include/public/gcov.h   | 115 --
 xen/include/public/sysctl.h |  38 +---
 xen/include/xen/gcov.h  |  93 --
 10 files changed, 2 insertions(+), 820 deletions(-)
 delete mode 100644 tools/misc/xencov.c
 delete mode 100755 tools/misc/xencov_split
 delete mode 100644 xen/common/gcov/gcov.c
 delete mode 100644 xen/include/public/gcov.h
 delete mode 100644 xen/include/xen/gcov.h

diff --git a/tools/misc/Makefile b/tools/misc/Makefile
index 8152f7b..5ba6672 100644
--- a/tools/misc/Makefile
+++ b/tools/misc/Makefile
@@ -13,7 +13,6 @@ CFLAGS += $(CFLAGS_libxenstore)
 INSTALL_BIN-$(CONFIG_X86)  += xen-cpuid
 INSTALL_BIN-$(CONFIG_X86)  += xen-detect
 INSTALL_BIN+= xencons
-INSTALL_BIN+= xencov_split
 INSTALL_BIN += $(INSTALL_BIN-y)
 
 # Everything to be installed in regular sbin/
@@ -25,7 +24,6 @@ INSTALL_SBIN-$(CONFIG_X86) += xen-lowmemd
 INSTALL_SBIN-$(CONFIG_X86) += xen-mfndump
 INSTALL_SBIN   += xen-ringwatch
 INSTALL_SBIN   += xen-tmem-list-parse
-INSTALL_SBIN   += xencov
 INSTALL_SBIN   += xenlockprof
 INSTALL_SBIN   += xenperf
 INSTALL_SBIN   += xenpm
@@ -43,7 +41,6 @@ TARGETS_ALL := $(INSTALL_BIN) $(INSTALL_SBIN) 
$(INSTALL_PRIVBIN)
 TARGETS_COPY += xen-bugtool
 TARGETS_COPY += xen-ringwatch
 TARGETS_COPY += xencons
-TARGETS_COPY += xencov_split
 TARGETS_COPY += xenpvnetboot
 
 # Everything which needs to be built
@@ -105,7 +102,4 @@ xen-livepatch: xen-livepatch.o
 xen-lowmemd: xen-lowmemd.o
$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenevtchn) $(LDLIBS_libxenctrl) 
$(LDLIBS_libxenstore) $(APPEND_LDFLAGS)
 
-xencov: xencov.o
-   $(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
-
 -include $(DEPS)
diff --git a/tools/misc/xencov.c b/tools/misc/xencov.c
deleted file mode 100644
index 2aafb1d..000
--- a/tools/misc/xencov.c
+++ /dev/null
@@ -1,147 +0,0 @@
-/*
- * xencov: handle test coverage information from Xen.
- *
- * Copyright (c) 2013, Citrix Systems R Ltd.
- *
- * 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 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 
-
-static xc_interface *gcov_xch = NULL;
-
-static void gcov_init(void)
-{
-gcov_xch = xc_interface_open(NULL, NULL, 0);
-if ( !gcov_xch )
-err(1, "opening interface");
-}
-
-int gcov_get_info(int op, struct xen_sysctl *sys, struct xc_hypercall_buffer 
*ptr)
-{
-struct xen_sysctl_coverage_op *cov;
-DECLARE_HYPERCALL_BUFFER_ARGUMENT(ptr);
-
-memset(sys, 0, sizeof(*sys));
-sys->cmd = XEN_SYSCTL_coverage_op;
-
-cov = >u.coverage_op;
-cov->cmd = op;
-set_xen_guest_handle(cov->u.raw_info, ptr);
-
-return xc_sysctl(gcov_xch, sys);
-}
-
-static void gcov_read(const char *fn, int reset)
-{
-struct xen_sysctl sys;
-uint32_t total_len;
-DECLARE_HYPERCALL_BUFFER(uint8_t, p);
-FILE *f;
-int op = reset ? XEN_SYSCTL_COVERAGE_read_and_reset :
- XEN_SYSCTL_COVERAGE_read;
-
-/* get total length */
-if ( gcov_get_info(XEN_SYSCTL_COVERAGE_get_total_size, , NULL) < 0 )
-err(1, "getting total length");
-total_len = sys.u.coverage_op.u.total_size;
-fprintf(stderr, "returned %u bytes\n",

[Xen-devel] [PATCH v2 2/9] Kconfig: add BROKEN config

2016-10-10 Thread Wei Liu

Used to hide feature that is completely broken.

Signed-off-by: Wei Liu 
---
v2: use tab

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

diff --git a/xen/Kconfig b/xen/Kconfig
index 0fe7a1a..5515fe9 100644
--- a/xen/Kconfig
+++ b/xen/Kconfig
@@ -12,6 +12,9 @@ config ARCH
string
option env="ARCH"
 
+config BROKEN
+   bool
+
 source "arch/$SRCARCH/Kconfig"
 
 config XEN_FULLVERSION
-- 
2.1.4


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

[Xen-devel] [PATCH v2 0/9] Rework gcov support in Xen

2016-10-10 Thread Wei Liu

The original implementation of gcov support in Xen has several
limitations:

1. The internal data structures are tied to gcc 3.4 format.
2. The sysctl interface is tied to gcc 3.4 format.
3. The gcov type definition is wrong, doesn't work with 32 bit
   hypervisor, which means arm32 wouldn't work.

Since the hypervisor interface is sysctl, we have the liberty to not
care about backward compatibility. This series completely rewrites the
gcov support inside Xen.

1. Support both gcc 3.4 and 4.7 format, configurable via Kconfig.
2. The sysctl interface is not tied to particular gcc format version.
3. Should work with arm32.

I have tested using both formats on x86. I was able to get gcov to
recognise the extracted data. I haven't really analyse the data in
detail though.

The patch series mostly consists of two parts. The meat is in the
first few patches. A few other patches are added to make available
automatic format detection.

There are still some rough edges, but I feel that this is good enough to post
so that people can review the sysctl interface.

This series can be found at:

git://xenbits.xen.org/people/liuw/xen.git wip.rework-gcov-v$VERSION

Wei.

---
v2: see individual commits for changes.

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

Wei Liu (9):
  Kconfig: use tab instead of space
  Kconfig: add BROKEN config
  xen: delete gcno files in clean target
  xen, tools: rip out old gcov implementation
  gcov: add new interface and 3.4 and 4.7 format support
  gcov: userspace tools to extract and split gcov data
  Config.mk: expand cc-ver a bit
  Config.mk: introduce cc-ifversion
  gcov: provide the capability to select gcov format automatically

 Config.mk   |  13 +-
 tools/misc/xencov.c | 111 +++---
 tools/misc/xencov_split | 288 ---
 xen/Kconfig |   3 +
 xen/Kconfig.debug   |  36 -
 xen/Makefile|   2 +-
 xen/common/gcov/Makefile|   7 +-
 xen/common/gcov/gcc_3_4.c   | 363 
 xen/common/gcov/gcc_4_7.c   | 201 
 xen/common/gcov/gcov.c  | 308 -
 xen/common/gcov/gcov.h  |  36 +
 xen/common/gcov/gcov_base.c |  64 
 xen/common/sysctl.c |   7 +-
 xen/include/public/gcov.h   | 115 --
 xen/include/public/sysctl.h |  61 
 xen/include/xen/gcov.h  |  94 +---
 16 files changed, 1076 insertions(+), 633 deletions(-)
 create mode 100644 xen/common/gcov/gcc_3_4.c
 create mode 100644 xen/common/gcov/gcc_4_7.c
 create mode 100644 xen/common/gcov/gcov.h
 create mode 100644 xen/common/gcov/gcov_base.c
 delete mode 100644 xen/include/public/gcov.h

-- 
2.1.4


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

[Xen-devel] [PATCH v2 6/9] gcov: userspace tools to extract and split gcov data

2016-10-10 Thread Wei Liu

Provide two tools: a small C program to extract data from hypervisor and
a python script to split data into multiple files.

The file xencov.c is salvaged and modified from the original xencov.c.

Signed-off-by: Wei Liu 
---
v2: fix INSTALL_BIN typo

Cc: Ian Jackson 
---
 tools/misc/Makefile |   6 ++
 tools/misc/xencov.c | 148 
 tools/misc/xencov_split | 100 
 3 files changed, 254 insertions(+)
 create mode 100644 tools/misc/xencov.c
 create mode 100755 tools/misc/xencov_split

diff --git a/tools/misc/Makefile b/tools/misc/Makefile
index 5ba6672..8152f7b 100644
--- a/tools/misc/Makefile
+++ b/tools/misc/Makefile
@@ -13,6 +13,7 @@ CFLAGS += $(CFLAGS_libxenstore)
 INSTALL_BIN-$(CONFIG_X86)  += xen-cpuid
 INSTALL_BIN-$(CONFIG_X86)  += xen-detect
 INSTALL_BIN+= xencons
+INSTALL_BIN+= xencov_split
 INSTALL_BIN += $(INSTALL_BIN-y)
 
 # Everything to be installed in regular sbin/
@@ -24,6 +25,7 @@ INSTALL_SBIN-$(CONFIG_X86) += xen-lowmemd
 INSTALL_SBIN-$(CONFIG_X86) += xen-mfndump
 INSTALL_SBIN   += xen-ringwatch
 INSTALL_SBIN   += xen-tmem-list-parse
+INSTALL_SBIN   += xencov
 INSTALL_SBIN   += xenlockprof
 INSTALL_SBIN   += xenperf
 INSTALL_SBIN   += xenpm
@@ -41,6 +43,7 @@ TARGETS_ALL := $(INSTALL_BIN) $(INSTALL_SBIN) 
$(INSTALL_PRIVBIN)
 TARGETS_COPY += xen-bugtool
 TARGETS_COPY += xen-ringwatch
 TARGETS_COPY += xencons
+TARGETS_COPY += xencov_split
 TARGETS_COPY += xenpvnetboot
 
 # Everything which needs to be built
@@ -102,4 +105,7 @@ xen-livepatch: xen-livepatch.o
 xen-lowmemd: xen-lowmemd.o
$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenevtchn) $(LDLIBS_libxenctrl) 
$(LDLIBS_libxenstore) $(APPEND_LDFLAGS)
 
+xencov: xencov.o
+   $(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
+
 -include $(DEPS)
diff --git a/tools/misc/xencov.c b/tools/misc/xencov.c
new file mode 100644
index 000..d83bc66
--- /dev/null
+++ b/tools/misc/xencov.c
@@ -0,0 +1,148 @@
+/*
+ * xencov: extract test coverage information from Xen.
+ *
+ * Copyright (c) 2013, 2016, Citrix Systems R Ltd.
+ *
+ * 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 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 
+
+static xc_interface *xch = NULL;
+
+int gcov_sysctl(int op, struct xen_sysctl *sysctl,
+struct xc_hypercall_buffer *buf, uint32_t buf_size)
+{
+DECLARE_HYPERCALL_BUFFER_ARGUMENT(buf);
+
+memset(sysctl, 0, sizeof(*sysctl));
+sysctl->cmd = XEN_SYSCTL_gcov_op;
+
+sysctl->u.gcov_op.cmd = op;
+sysctl->u.gcov_op.size = buf_size;
+set_xen_guest_handle(sysctl->u.gcov_op.buffer, buf);
+
+return xc_sysctl(xch, sysctl);
+}
+
+static void gcov_read(const char *fn)
+{
+struct xen_sysctl sys;
+uint32_t total_len;
+DECLARE_HYPERCALL_BUFFER(uint8_t, p);
+FILE *f;
+
+if (gcov_sysctl(XEN_SYSCTL_GCOV_get_size, , NULL, 0) < 0)
+err(1, "getting total length");
+total_len = sys.u.gcov_op.size;
+
+/* Shouldn't exceed a few hundred kilobytes */
+if (total_len > 8u * 1024u * 1024u)
+errx(1, "gcov data too big %u bytes\n", total_len);
+
+p = xc_hypercall_buffer_alloc(xch, p, total_len);
+if (!p)
+err(1, "allocating buffer");
+
+memset(p, 0, total_len);
+if (gcov_sysctl(XEN_SYSCTL_GCOV_read, , HYPERCALL_BUFFER(p),
+total_len) < 0)
+err(1, "getting gcov data");
+
+if (!strcmp(fn, "-"))
+f = stdout;
+else
+f = fopen(fn, "w");
+
+if (!f)
+err(1, "opening output file");
+
+if (fwrite(p, 1, total_len, f) != total_len)
+err(1, "writing gcov data to file");
+
+if (f != stdout)
+fclose(f);
+
+xc_hypercall_buffer_free(xch, p);
+}
+
+static void gcov_reset(void)
+{
+struct xen_sysctl sys;
+
+if (gcov_sysctl(XEN_SYSCTL_GCOV_reset, , NULL, 0) < 0)
+err(1, "resetting gcov information");
+}
+
+static void usage(int exit_code)
+{
+FILE *out = exit_code ? stderr : stdout;
+
+fprintf(out, "xencov {reset|read} []\n"
+"\treset   reset information\n"
+"\treadread information from xen to filename\n"
+"\tfilenameoptional filename (default

[Xen-devel] [PATCH v2 3/9] xen: delete gcno files in clean target

2016-10-10 Thread Wei Liu

Signed-off-by: Wei Liu 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
 xen/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/Makefile b/xen/Makefile
index c511330..48dbbba 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -116,7 +116,7 @@ _clean: delete-unfresh-files
$(MAKE) -f $(BASEDIR)/Rules.mk -C arch/$(TARGET_ARCH) clean
$(MAKE) -f $(BASEDIR)/Rules.mk -C test clean
$(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig ARCH=$(ARCH) 
SRCARCH=$(SRCARCH) clean
-   find . \( -name "*.o" -o -name ".*.d" \) -exec rm -f {} \;
+   find . \( -name "*.o" -o -name ".*.d" -o -name "*.gcno" \) -exec rm -f 
{} \;
rm -f include/asm $(TARGET) $(TARGET).gz $(TARGET).efi 
$(TARGET).efi.map $(TARGET)-syms $(TARGET)-syms.map *~ core
rm -f include/asm-*/asm-offsets.h
rm -f .banner
-- 
2.1.4


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

[Xen-devel] [PATCH v2 7/9] Config.mk: expand cc-ver a bit

2016-10-10 Thread Wei Liu

... so that we can do other comparisons as well.

No functional change.

Signed-off-by: Wei Liu 
---
v2: move dash into macro.

Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
 Config.mk | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/Config.mk b/Config.mk
index 3c3ff68..af50137 100644
--- a/Config.mk
+++ b/Config.mk
@@ -112,17 +112,17 @@ endef
 
 cc-options-add = $(foreach o,$(3),$(call cc-option-add,$(1),$(2),$(o)))
 
-# cc-ver: Check compiler is at least specified version. Return boolean 'y'/'n'.
-# Usage: ifeq ($(call cc-ver,$(CC),0x030400),y)
+# cc-ver: Check compiler against the version requirement. Return boolean 
'y'/'n'.
+# Usage: ifeq ($(call cc-ver,$(CC),ge,0x030400),y)
 cc-ver = $(shell if [ $$((`$(1) -dumpversion | awk -F. \
-   '{ printf "0x%02x%02x%02x", $$1, $$2, $$3}'`)) -ge $$(($(2))) ]; \
+   '{ printf "0x%02x%02x%02x", $$1, $$2, $$3}'`)) -$(2) $$(($(3))) ]; \
then echo y; else echo n; fi ;)
 
 # cc-ver-check: Check compiler is at least specified version, else fail.
 # Usage: $(call cc-ver-check,CC,0x030400,"Require at least gcc-3.4")
 cc-ver-check = $(eval $(call cc-ver-check-closure,$(1),$(2),$(3)))
 define cc-ver-check-closure
-ifeq ($$(call cc-ver,$$($(1)),$(2)),n)
+ifeq ($$(call cc-ver,$$($(1)),ge,$(2)),n)
 override $(1) = echo "*** FATAL BUILD ERROR: "$(3) >&2; exit 1;
 cc-option := n
 endif
-- 
2.1.4


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

[Xen-devel] [PATCH v2 5/9] gcov: add new interface and 3.4 and 4.7 format support

2016-10-10 Thread Wei Liu

A new sysctl interface for passing gcov data back to userspace. The new
interface uses a customised record file format. The new sysctl reuses
original sysctl number but renames the op to gcov_op.

Both gcc 3.4 and 4.7 format are supported. The code is rewritten so that
a new format can be easily added in the future.  Version specific code
is grouped into different files. The format one needs to use can be
picked via Kconfig. The default format is 4.7 format.

Userspace programs to handle extracted data will come in a later patch.

Signed-off-by: Wei Liu 
---
v2:
1. Use tab in Kconfig and indent help text properly.
2. Bump XEN_SYSCTL_INTERFACE_VERSION.
3. Fix cosmetic issues.

Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
 xen/Kconfig.debug   |  24 ++-
 xen/common/gcov/Makefile|   3 +
 xen/common/gcov/gcc_3_4.c   | 363 
 xen/common/gcov/gcc_4_7.c   | 201 
 xen/common/gcov/gcov.c  | 257 +++
 xen/common/gcov/gcov.h  |  36 +
 xen/common/gcov/gcov_base.c |  64 
 xen/common/sysctl.c |   8 +
 xen/include/public/sysctl.h |  39 -
 xen/include/xen/gcov.h  |   9 ++
 10 files changed, 997 insertions(+), 7 deletions(-)
 create mode 100644 xen/common/gcov/gcc_3_4.c
 create mode 100644 xen/common/gcov/gcc_4_7.c
 create mode 100644 xen/common/gcov/gcov.c
 create mode 100644 xen/common/gcov/gcov.h
 create mode 100644 xen/common/gcov/gcov_base.c
 create mode 100644 xen/include/xen/gcov.h

diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
index ef863dc..c65e543 100644
--- a/xen/Kconfig.debug
+++ b/xen/Kconfig.debug
@@ -30,16 +30,30 @@ config FRAME_POINTER
 
 config GCOV
bool "Gcov Support"
-   depends on BROKEN
---help---
  Enable gcov (a test coverage program in GCC) support.
 
- Currently the data structure and hypercall interface are tied
- to GCC 3.4 gcov format. You need to have a version of GCC
- that is compatible with that format to make gcov work.
-
  If unsure, say N here.
 
+choice
+   prompt "Specify Gcov format"
+   depends on GCOV
+   default GCOV_FORMAT_4_7
+   ---help---
+ The gcov format is determined by gcc version.
+
+config GCOV_FORMAT_4_7
+   bool "GCC 4.7 format"
+   ---help---
+ Select this option to use the format specified in GCC 4.7.
+
+config GCOV_FORMAT_3_4
+   bool "GCC 3.4 format"
+   ---help---
+ Select this option to use the format specified in GCC 3.4.
+
+endchoice
+
 config LOCK_PROFILE
bool "Lock Profiling"
---help---
diff --git a/xen/common/gcov/Makefile b/xen/common/gcov/Makefile
index e69de29..03ac1e5 100644
--- a/xen/common/gcov/Makefile
+++ b/xen/common/gcov/Makefile
@@ -0,0 +1,3 @@
+obj-y += gcov_base.o gcov.o
+obj-$(CONFIG_GCOV_FORMAT_3_4) += gcc_3_4.o
+obj-$(CONFIG_GCOV_FORMAT_4_7) += gcc_4_7.o
diff --git a/xen/common/gcov/gcc_3_4.c b/xen/common/gcov/gcc_3_4.c
new file mode 100644
index 000..2b62b3f
--- /dev/null
+++ b/xen/common/gcov/gcc_3_4.c
@@ -0,0 +1,363 @@
+/*
+ *  This code provides functions to handle gcc's profiling data format
+ *  introduced with gcc 3.4. Future versions of gcc may change the gcov
+ *  format (as happened before), so all format-specific information needs
+ *  to be kept modular and easily exchangeable.
+ *
+ *  This file is based on gcc-internal definitions. Functions and data
+ *  structures are defined to be compatible with gcc counterparts.
+ *  For a better understanding, refer to gcc source: gcc/gcov-io.h.
+ *
+ *Copyright IBM Corp. 2009
+ *Author(s): Peter Oberparleiter 
+ *
+ *Uses gcc-internal data definitions.
+ *
+ *  Imported from Linux and modified for Xen by
+ *Wei Liu 
+ */
+
+
+#include 
+
+#include "gcov.h"
+
+#define GCOV_COUNTERS 5
+
+static struct gcov_info *gcov_info_head;
+
+/**
+ * struct gcov_fn_info - profiling meta data per function
+ * @ident: object file-unique function identifier
+ * @checksum: function checksum
+ * @n_ctrs: number of values per counter type belonging to this function
+ *
+ * This data is generated by gcc during compilation and doesn't change
+ * at run-time.
+ */
+struct gcov_fn_info
+{
+unsigned int ident;
+unsigned int checksum;
+unsigned int n_ctrs[0];
+};
+
+/**
+ * struct gcov_ctr_info - profiling data per counter type
+ * @num: number of counter values for this type
+ * @values: array of counter values for this type
+ * @merge: merge function for counter values of this type (unused)
+ *
+ * This data is generated by gcc during compilation and

1 2 >

1 - 100 of 126 matches

Mail list logo