Re: [Xen-devel] [PATCH] xen: Use ULL for GB macro

[Jan Beulich]

>>> On 22.05.15 at 01:16,  wrote:
> --- a/xen/arch/x86/apic.c
> +++ b/xen/arch/x86/apic.c
> @@ -992,7 +992,7 @@ void __init init_apic_mappings(void)
>  apic_phys = mp_lapic_addr;
>  
>  set_fixmap_nocache(FIX_APIC_BASE, apic_phys);
> -apic_printk(APIC_VERBOSE, "mapped APIC to %08lx (%08lx)\n", APIC_BASE,
> +apic_printk(APIC_VERBOSE, "mapped APIC to %08llx (%08lx)\n", APIC_BASE,

Please use 'L' as the shorter equivalent.

> --- a/xen/include/xen/config.h
> +++ b/xen/include/xen/config.h
> @@ -70,7 +70,7 @@
>  #define __bitwise
>  
>  #define MB(_mb) (_AC(_mb, UL) << 20)
> -#define GB(_gb) (_AC(_gb, UL) << 30)
> +#define GB(_gb) (_AC(_gb, ULL) << 30)

So why do you leave MB() alone? It obviously suffers from the same
problem (perhaps only latent at this point, but anyway).

Jan


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

[Xen-devel] [seabios test] 56932: tolerable FAIL - PUSHED

[osstest service user]

flight 56932 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/56932/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64  9 windows-install fail like 55291

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail never 
pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail never 
pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass

version targeted for testing:
 seabios  3752bf44be8931f86523ed538555b170a52d09dc
baseline version:
 seabios  92f9b9189eb00da42a8bfcf26c664f48ee8d2868


People who touched revisions under test:
  Vladimir Serbinenko 


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-debianhvm-amd64-xsmfail
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm fail
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-i386-qemuu-rhel6hvm-intel pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
 test-amd64-amd64-xl-qemuu-winxpsp3   pass
 test-amd64-i386-xl-qemuu-winxpsp3pass



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

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


Pushing revision :

+ branch=seabios
+ revision=3752bf44be8931f86523ed538555b170a52d09dc
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
++ 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 seabios 
3752bf44be8931f86523ed538555b170a52d09dc
+ branch=seabios
+ revision=3752bf44be8931f86523ed538555b170a52d09dc
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
++ 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=seabios
+ xenbranch=xen-unstable
+ '[' xseabios = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : 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/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'

Re: [Xen-devel] [PATCHv9 3/4] gnttab: make the grant table lock a read-write lock

[Jan Beulich]

>>> On 21.05.15 at 17:16,  wrote:
> On 21/05/15 15:53, Jan Beulich wrote:
> On 21.05.15 at 15:36,  wrote:
>>> On 21/05/15 11:32, Jan Beulich wrote:
>>> On 20.05.15 at 17:54,  wrote:
> @@ -827,9 +828,11 @@ __gnttab_map_grant_ref(
>  if ( (wrc + rdc) == 0 )
>  err = iommu_map_page(ld, frame, frame, IOMMUF_readable);
>  }
> +
> +double_gt_lock(lgt, rgt);

 unlock. And with this code path actually used (due to the bug it's
 pretty clear it didn't get exercised in your testing), how does
 performance look like? 
>>>
>>> I think it will be no worse than what it was before -- this path already
>>> really sucks (mapcount() loops over 1000s of entries).  I don't care
>>> about this path at all.
>> 
>> It's kind of strange that you don't care about this case - afaict we're
>> not getting there by default solely because dom0-strict mode is not
>> currently the default (albeit arguably it should be).
> 
> What's your point?  Are you going to refuse this series unless it also
> optimizes dom0-strict mode?

No, I'm certainly not going to be. But this series of "I don't care"
worry me to a certain degree (apart from making me wonder
why, as so far I thought an as secure as possible environment is
key for XenServer, and "iommu=dom0-strict" is certainly helping
with that, which is also why I said that this should arguably
become the default).

Jan


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

[Xen-devel] [PATCH] x86/shadow: fix uninitialized rc shadow_track_dirty_vram()

[Jan Beulich]

Commit bd1b4a71b3 ("x86/shadow: fix shadow_track_dirty_vram to work on
hvm guests"), trying to mirror its HAP counterpart, deleted a couple of
assignments to rc without making sure rc is initialized on all paths.

Coverity ID: 1299410
Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -3518,7 +3518,7 @@ int shadow_track_dirty_vram(struct domain
 unsigned long nr,
 XEN_GUEST_HANDLE_64(uint8) guest_dirty_bitmap)
 {
-int rc;
+int rc = 0;
 unsigned long end_pfn = begin_pfn + nr;
 unsigned long dirty_size = (nr + 7) / 8;
 int flush_tlb = 0;
@@ -3550,10 +3550,7 @@ int shadow_track_dirty_vram(struct domain
 }
 
 if ( !nr )
-{
-rc = 0;
 goto out;
-}
 
 dirty_bitmap = vzalloc(dirty_size);
 if ( dirty_bitmap == NULL )




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

Re: [Xen-devel] [PATCH] x86/VT-x: Align segment table columns when dumping a VMCS

[Tian, Kevin]

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Wednesday, May 20, 2015 10:05 PM
> 
> This makes it more succinct and easier to read.
> 
> Before:
>   (XEN) Sysenter RSP= CS:RIP=:
>   (XEN) CS: sel=0x0008, attr=0x0c09b, limit=0x,
> base=0x
>   (XEN) DS: sel=0x0010, attr=0x0c093, limit=0x,
> base=0x
>   (XEN) SS: sel=0x0010, attr=0x0c093, limit=0x,
> base=0x
>   (XEN) ES: sel=0x0010, attr=0x0c093, limit=0x,
> base=0x
>   (XEN) FS: sel=0x, attr=0x00093, limit=0x,
> base=0x
>   (XEN) GS: sel=0x, attr=0x00093, limit=0x,
> base=0x
>   (XEN) GDTR:   limit=0x0017,
> base=0x00102eb8
>   (XEN) LDTR: sel=0x, attr=0x00082, limit=0x,
> base=0x
>   (XEN) IDTR:   limit=0x,
> base=0x
>   (XEN) TR: sel=0x, attr=0x0008b, limit=0x,
> base=0x
>   (XEN) EFER = 0x  PAT = 0x0007040600070406
> 
> After:
>   (XEN) Sysenter RSP= CS:RIP=:
>   (XEN)sel  attr  limit   base
>   (XEN)   CS: 0008 0c09b  
>   (XEN)   DS: 0010 0c093  
>   (XEN)   SS: 0010 0c093  
>   (XEN)   ES: 0010 0c093  
>   (XEN)   FS:  00093  
>   (XEN)   GS:  00093  
>   (XEN) GDTR:0017 00102eb8
>   (XEN) LDTR:  00082  
>   (XEN) IDTR: 
>   (XEN)   TR:  0008b  
>   (XEN) EFER = 0x  PAT = 0x0007040600070406
> 
> Signed-off-by: Andrew Cooper 
> CC: Keir Fraser 
> CC: Jan Beulich 
> CC: Jun Nakajima 
> CC: Eddie Dong 
> CC: Kevin Tian 

Acked-by: Kevin Tian 

> ---
>  xen/arch/x86/hvm/vmx/vmcs.c |   21 ++---
>  1 file changed, 10 insertions(+), 11 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
> index 355d1b5..877ec10 100644
> --- a/xen/arch/x86/hvm/vmx/vmcs.c
> +++ b/xen/arch/x86/hvm/vmx/vmcs.c
> @@ -1639,8 +1639,7 @@ static void vmx_dump_sel(char *name, uint32_t
> selector)
>  attr = vmr(selector + (GUEST_ES_AR_BYTES - GUEST_ES_SELECTOR));
>  limit = vmr(selector + (GUEST_ES_LIMIT - GUEST_ES_SELECTOR));
>  base = vmr(selector + (GUEST_ES_BASE - GUEST_ES_SELECTOR));
> -printk("%s: sel=0x%04x, attr=0x%05x, limit=0x%08x,
> base=0x%016"PRIx64"\n",
> -   name, sel, attr, limit, base);
> +printk("%s: %04x %05x %08x %016"PRIx64"\n", name, sel, attr, limit,
> base);
>  }
> 
>  static void vmx_dump_sel2(char *name, uint32_t lim)
> @@ -1649,8 +1648,7 @@ static void vmx_dump_sel2(char *name, uint32_t
> lim)
>  uint64_t base;
>  limit = vmr(lim);
>  base = vmr(lim + (GUEST_GDTR_BASE - GUEST_GDTR_LIMIT));
> -printk("%s:   limit=0x%08x,
> base=0x%016"PRIx64"\n",
> -   name, limit, base);
> +printk("%s:%08x %016"PRIx64"\n", name, limit, base);
>  }
> 
>  void vmcs_dump_vcpu(struct vcpu *v)
> @@ -1695,16 +1693,17 @@ void vmcs_dump_vcpu(struct vcpu *v)
>  printk("Sysenter RSP=%016lx CS:RIP=%04x:%016lx\n",
> vmr(GUEST_SYSENTER_ESP),
> vmr32(GUEST_SYSENTER_CS), vmr(GUEST_SYSENTER_EIP));
> -vmx_dump_sel("CS", GUEST_CS_SELECTOR);
> -vmx_dump_sel("DS", GUEST_DS_SELECTOR);
> -vmx_dump_sel("SS", GUEST_SS_SELECTOR);
> -vmx_dump_sel("ES", GUEST_ES_SELECTOR);
> -vmx_dump_sel("FS", GUEST_FS_SELECTOR);
> -vmx_dump_sel("GS", GUEST_GS_SELECTOR);
> +printk("   sel  attr  limit   base\n");
> +vmx_dump_sel("  CS", GUEST_CS_SELECTOR);
> +vmx_dump_sel("  DS", GUEST_DS_SELECTOR);
> +vmx_dump_sel("  SS", GUEST_SS_SELECTOR);
> +vmx_dump_sel("  ES", GUEST_ES_SELECTOR);
> +vmx_dump_sel("  FS", GUEST_FS_SELECTOR);
> +vmx_dump_sel("  GS", GUEST_GS_SELECTOR);
>  vmx_dump_sel2("GDTR", GUEST_GDTR_LIMIT);
>  vmx_dump_sel("LDTR", GUEST_LDTR_SELECTOR);
>  vmx_dump_sel2("IDTR", GUEST_IDTR_LIMIT);
> -vmx_dump_sel("TR", GUEST_TR_SELECTOR);
> +vmx_dump_sel("  TR", GUEST_TR_SELECTOR);
>  if ( (vmexit_ctl & (VM_EXIT_SAVE_GUEST_PAT |
> VM_EXIT_SAVE_GUEST_EFER)) ||
>   (vmentry_ctl & (VM_ENTRY_LOAD_GUEST_PAT |
> VM_ENTRY_LOAD_GUEST_EFER)) )
>  printk("EFER = 0x%016lx  PAT = 0x%016lx\n", efer,
> vmr(GUEST_PAT));
> --
> 1.7.10.4


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

Re: [Xen-devel] Plans for the SEDF scheduler

[Meng Xu]

[Add Chong and Dagaen who is working on improving RTDS scheduler now.]
> I'm less sure of libxl, because of the API stability claims. It looks
> like this is all about (as there are not scheduler specific API
> functions, which is good) this:
>
>  # Consistent with values defined in domctl.h
>  # Except unknown which we have made up
>  libxl_scheduler = Enumeration("scheduler", [
>  (0, "unknown"),
>  (4, "sedf"),
>  (5, "credit"),
>  (6, "credit2"),
>  (7, "arinc653"),
>  (8, "rtds"),
>  ])
>
> The solutions I see are:
>  1. get rid of the field. This does not sound ideal from an API
> stability point of view;
>  2. keep the field 'physically', but return warnings and errors when it
> is used. This is a change in behavior, so also not really stable
> (but, hey, the scheduler is going away, the behavior will change,
> one way or another!)
>  3. RTDS has a really similar interface and, to a certain extent, a
> similar behavior too. Would it make sense to, upon suitable
> warnings, of course, convert the requests within libxl, i.e.,
> when someone asks for SEDF, we give him RTDS?
>
> Honestly, I'd prefer 2, and I don't much like 3. However, it really
> seems that 3 gives us a way to keep most of our promises about API
> stability... Thoughts?

I think option 2) is better than the other two choices. The SEDF does
not use a strictly EDF scheduling policy as RTDS does, so the
scheduling sequence of VCPUs won't be same even when we tuned RTDS to
single-core EDF scheduler. This implicit transformation may give users
more difficulty to figure out how to use the real time scheduler in
Xen.

Thanks,

Meng


---
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania
http://www.cis.upenn.edu/~mengxu/

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

Re: [Xen-devel] [PATCH] x86/pvh: disable posted interrupts

[Tian, Kevin]

> From: Roger Pau Monne [mailto:roger@citrix.com]
> Sent: Thursday, May 21, 2015 8:15 PM
> 
> Enabling posted interrupts requires the virtual interrupt delivery feature,
> which is disabled for PVH guests, so make sure posted interrupts are also
> disabled or else vmlaunch will fail.
> 
> Signed-off-by: Roger Pau Monné 
> Reported-and-Tested-by: Lars Eggert 
> Cc: Jun Nakajima 
> Cc: Eddie Dong 
> Cc: Kevin Tian 
> Cc: Jan Beulich 
> Cc: Andrew Cooper 

Acked-by: Kevin Tian , if you fix the comment from Jan.

Thanks
Kevin

> ---
>  xen/arch/x86/hvm/vmx/vmcs.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
> index a714549..9827a8e 100644
> --- a/xen/arch/x86/hvm/vmx/vmcs.c
> +++ b/xen/arch/x86/hvm/vmx/vmcs.c
> @@ -980,6 +980,10 @@ static int construct_vmcs(struct vcpu *v)
>  v->arch.hvm_vmx.secondary_exec_control &=
>  ~SECONDARY_EXEC_UNRESTRICTED_GUEST;
> 
> +/* Disable posted interrupts */
> +__vmwrite(PIN_BASED_VM_EXEC_CONTROL,
> +vmx_pin_based_exec_control &
> ~PIN_BASED_POSTED_INTERRUPT);
> +
>  /* Start in 64-bit mode. PVH 32bitfixme. */
>  vmentry_ctl |= VM_ENTRY_IA32E_MODE;   /*
> GUEST_EFER.LME/LMA ignored */
> 
> --
> 1.9.5 (Apple Git-50.3)

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

Re: [Xen-devel] [PATCH] xl: Support (by ignoring) xl migrate --live

[Olaf Hering]

On Thu, May 21, Ian Campbell wrote:

> OOI what version of pod2text are you both using which exposes this?

perl 5.10 as included in SLE11 and 5.12 as included in 11.4 accept this.
But perl 5.18 as included in SLE12 and 13.1 reject it.

Olaf

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

Re: [Xen-devel] [PATCH RFC v1] libxl: Introduce a template for devices with a controller

[Juergen Gross]

On 05/21/2015 07:07 PM, George Dunlap wrote:

We have several outstanding patch series which add devices that have
two levels: a controller and individual devices attached to that
controller.

In the interest of consistency, this patch introduces a section that
sketches out a template for interfaces for such devices.

Signed-off-by: George Dunlap 
---
CC: Ian Campbell 
CC: Ian Jackson 
CC: Wei Liu 
CC: Juergen Gross 
CC: Chun Yan Liu 
CC: Olaf Hering 

So, this is definitely RFC -- I tried to spec things out in a way that
made sense, but I often just chose something that I thought would be a
sensible starting point for discussion.

This spec looks a lot more like the PVUSB spec than the PVSCSI spec,
in part because I think the PVUSB spec has already had a lot more
thought that's gone into it.

A couple of random points to discuss:

* Calling things "controllers", using ctrl for the device name,
   and using "ctrl" as the field name for the devid of the controller
   in the individual devices.


Hmm, what about "device group" (devgoup)? In the scsi world
"controller" would be one level higher in the hierarchy. And the scsi
controller is at least visible in the configuration syntax "h:c:t:l".
Using "controller" for the "c" in this item and for the "t" internally
could lead to confusion.


Juergen


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

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

[osstest service user]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-multivcpu 17 leak-check/check fail REGR. vs. 56375
 test-amd64-amd64-xl-qemuu-win7-amd64  9 windows-install   fail REGR. vs. 56375

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-libvirt 11 guest-start   fail REGR. vs. 56375
 test-armhf-armhf-libvirt 11 guest-start  fail   like 56375
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 56375
 test-amd64-i386-libvirt  11 guest-start  fail   like 56375
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 56375
 test-amd64-i386-freebsd10-amd64 13 guest-localmigrate   fail like 56943-bisect

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-xsm  14 guest-localmigrate   fail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-xl-xsm   14 guest-localmigrate   fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 12 guest-localmigrate fail never 
pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 12 guest-localmigrate fail never 
pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 12 guest-localmigrate fail never 
pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 12 guest-localmigrate fail never 
pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 11 guest-start  fail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-sedf-pin 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail never pass
 test-armhf-armhf-xl-sedf 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass

version targeted for testing:
 xen  b521422bd9c12719e6848c1be340df667ef41b52
baseline version:
 xen  e13013dbf1d5997915548a3b5f1c39594d8c1d7b


People who touched revisions under test:
  Andrew Cooper 
  Charles Arnold 
  Chen Baozi 
  Daniel De Graaf 
  David Vrabel 
  George Dunlap 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Julien Grall  (ARM)
  Julien Grall 
  Konrad Rzeszutek Wilk 
  Len Brown 
  Olaf Hering 
  Pranavkumar Sawargaonkar 
  Roger Pau Monné 
  Tiejun Chen 
  Tim Deegan 
  Wei Liu 


jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-oldkern  pass
 build-i386-oldkern   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  pass
 build-i386-rumpuserxen   pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsmfail
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm fail
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmfail
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm fail
 test-amd64-amd64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm fail
 test-amd64-i386-libvirt-xsm  p

Re: [Xen-devel] [PATCH v10 3/6] Support for BIOS interrupt handler

[Xu, Quan]

> -Original Message-
> From: Kevin O'Connor [mailto:ke...@koconnor.net]
> Sent: Friday, May 22, 2015 1:20 AM
> To: Stefan Berger
> Cc: Xu, Quan; seab...@seabios.org; stefano.stabell...@eu.citrix.com;
> xen-devel@lists.xen.org; Daniel De Graaf; wei.l...@citrix.com
> Subject: Re: [PATCH v10 3/6] Support for BIOS interrupt handler
> 
> On Thu, Apr 30, 2015 at 11:34:20AM -0400, Stefan Berger wrote:
> > On 04/30/2015 09:21 AM, Xu, Quan wrote:
> > >
> > >Stefan,
> > >   Sorry to reply so late to you. I try to make it compatible with Xen
> > >vTPM by below patch Against your serious of
> patch(https://github.com/KevinOConnor/seabios/tree/tcg-testing ).
> > >Also I have tested this patch, which is working.
> [...]
> >
> > Kevin, I think this should be good to add after 3/6 ?
> 
> Thanks - I applied the first three tpm patches along with this patch.
> 
> -Kevin

Thanks :))


Quan

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

Re: [Xen-devel] [PATCH v6 1/4] pci: add pci_iomap_wc() variants

[Luis R. Rodriguez]

On Thu, May 21, 2015 at 05:33:21PM -0500, Bjorn Helgaas wrote:
> 
> I tentatively put this (and the rest of the series) on a pci/resource
> branch.  I'm hoping you'll propose some clarification about
> EXPORT_SYMBOL_GPL().

EXPORT_SYMBOL_GPL() also serves to ensure only GPL modules can
only run that code. So for instance although we have "Dual BSD/GPL"
tags for modules pure "BSD" tags do not exist for module tags and
cannot run EXPORT_SYMBOL_GPL() code [0]. Also there is some folks
who do believe tha at run time all kernel modules are GPL [1] [2].
And to be precise even though the FSF may claim a list of licenses
are GPL-compatible we cannot rely on this list alone for our own
goals and if folks want to use our EXPORT_SYMBOL_GPL()s they must
discuss this on lkml [2].

In the past when I've tried to try to clarify EXPORT_SYMBOL_GPL()
requirements, implications, its been said that its best to leave
some things as-is [3] and let attorneys figure things out. In so
far as to what exactly it is and can be used for requires legal
attorney review, but the question of derivative work certainly
comes up [4]. Now folks companies seem to want to obviously use
and abuse our symbols despite of all the things above, for instance
Red Hat once tried to change an EXPORT_SYMBOL_GPL() to
EXPORT_SYMBOL() [5]. Obviously that didn't go so well, and some
folks went off on a good rant about this [6].

What developers do and accept varies, I'm not going into pointing
out specifics and I do not wnat to do homework for folks who wish
to abuse things further, but by no means should a developer be
nack'd entry to new code if their functionality is not replacing
old one [9]. In this case this is new functionality. Also in terms
of preference:

"nobody has said that symbols exported with plain EXPORT_SYMBOL() can be freely
used by proprietary code; indeed, a number of developers claim that all (or
nearly all) loadable modules are derived products of the kernel regardless of
whether they use GPL-only symbols or not" [7].

And spot on:

"In general, the kernel community has long worked to maintain a vague and scary
ambiguity around the legal status of proprietary modules while being unwilling
to attempt to ban such modules outright." [7].

Now, a few maintainers insist on tons of new symbols to be EXPORT_SYMBOL_GPL()
though proactively [8] [9] and the reasons vary, I just happen to also write my
code to be perfectly clear with my goals and intent and you are the first to
ask me to reconsider this, even if you do make me use EXPORT_SYMBOL() my intent
and goal does not change, as with others. No code I ever write should be used
by proprietary shit, and I hope to convince others of the importance to do this
as well.

> In the meantime, I tried to make the changelog a bit more concise, as
> below.  Let me know if I omitted something essential.  We still have URLs
> for the discussion for the fine points.

Looks good.

[0] https://lkml.org/lkml/2012/4/7/102
[1] https://lkml.org/lkml/2012/4/8/71
[2] https://lkml.org/lkml/2012/4/8/71
[3] https://lkml.org/lkml/2009/6/1/385
[4] https://lkml.org/lkml/2009/6/1/376
[5] https://lkml.org/lkml/2012/4/20/328
[6] https://plus.google.com/+AlanCoxLinux/posts/D2feRNc6R4d
[7] https://lwn.net/Articles/603131/
[8] https://lwn.net/Articles/603139/
[9] https://lkml.org/lkml/2015/2/26/379

  Luis

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

[Xen-devel] [PATCH v5 2/2] xen/block: add multi-page ring support

[Bob Liu]

Extend xen/block to support multi-page ring, so that more requests can be
issued by using more than one pages as the request ring between blkfront
and backend.
As a result, the performance can get improved significantly.

We got some impressive improvements on our highend iscsi storage cluster
backend. If using 64 pages as the ring, the IOPS increased about 15 times
for the throughput testing and above doubled for the latency testing.

The reason was the limit on outstanding requests is 32 if use only one-page
ring, but in our case the iscsi lun was spread across about 100 physical
drives, 32 was really not enough to keep them busy.

Changes in v2:
 - Rebased to 4.0-rc6.
 - Document on how multi-page ring feature working to linux io/blkif.h.

Changes in v3:
 - Remove changes to linux io/blkif.h and follow the protocol defined
   in io/blkif.h of XEN tree.
 - Rebased to 4.1-rc3

Changes in v4:
 - Turn to use 'ring-page-order' and 'max-ring-page-order'.
 - A few comments from Roger.

Changes in v5:
 - Clarify 4k granularity to comment.
 - Address more comments from Roger.

Signed-off-by: Bob Liu 
---
 drivers/block/xen-blkback/blkback.c |  13 
 drivers/block/xen-blkback/common.h  |   3 +-
 drivers/block/xen-blkback/xenbus.c  |  88 +--
 drivers/block/xen-blkfront.c| 135 +---
 4 files changed, 179 insertions(+), 60 deletions(-)

diff --git a/drivers/block/xen-blkback/blkback.c 
b/drivers/block/xen-blkback/blkback.c
index 713fc9f..2126842 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -84,6 +84,13 @@ MODULE_PARM_DESC(max_persistent_grants,
  "Maximum number of grants to map persistently");
 
 /*
+ * Maximum order of pages to be used for the shared ring between front and
+ * backend, 4KB page granularity is used.
+ */
+unsigned int xen_blkif_max_ring_order = XENBUS_MAX_RING_PAGE_ORDER;
+module_param_named(max_ring_page_order, xen_blkif_max_ring_order, int, 
S_IRUGO);
+MODULE_PARM_DESC(max_ring_page_order, "Maximum order of pages to be used for 
the shared ring");
+/*
  * The LRU mechanism to clean the lists of persistent grants needs to
  * be executed periodically. The time interval between consecutive executions
  * of the purge mechanism is set in ms.
@@ -1438,6 +1445,12 @@ static int __init xen_blkif_init(void)
if (!xen_domain())
return -ENODEV;
 
+   if (xen_blkif_max_ring_order > XENBUS_MAX_RING_PAGE_ORDER) {
+   pr_info("Invalid max_ring_order (%d), will use default max: 
%d.\n",
+   xen_blkif_max_ring_order, XENBUS_MAX_RING_PAGE_ORDER);
+   xen_blkif_max_ring_order = XENBUS_MAX_RING_PAGE_ORDER;
+   }
+
rc = xen_blkif_interface_init();
if (rc)
goto failed_init;
diff --git a/drivers/block/xen-blkback/common.h 
b/drivers/block/xen-blkback/common.h
index f620b5d..919a1ab 100644
--- a/drivers/block/xen-blkback/common.h
+++ b/drivers/block/xen-blkback/common.h
@@ -44,6 +44,7 @@
 #include 
 #include 
 
+extern unsigned int xen_blkif_max_ring_order;
 /*
  * This is the maximum number of segments that would be allowed in indirect
  * requests. This value will also be passed to the frontend.
@@ -248,7 +249,7 @@ struct backend_info;
 #define PERSISTENT_GNT_WAS_ACTIVE  1
 
 /* Number of requests that we can fit in a ring */
-#define XEN_BLKIF_REQS 32
+#define XEN_MAX_BLKIF_REQS (32 * XENBUS_MAX_RING_PAGES)
 
 struct persistent_gnt {
struct page *page;
diff --git a/drivers/block/xen-blkback/xenbus.c 
b/drivers/block/xen-blkback/xenbus.c
index 6ab69ad..bc33888 100644
--- a/drivers/block/xen-blkback/xenbus.c
+++ b/drivers/block/xen-blkback/xenbus.c
@@ -25,6 +25,7 @@
 
 /* Enlarge the array size in order to fully show blkback name. */
 #define BLKBACK_NAME_LEN (20)
+#define RINGREF_NAME_LEN (20)
 
 struct backend_info {
struct xenbus_device*dev;
@@ -152,7 +153,7 @@ static struct xen_blkif *xen_blkif_alloc(domid_t domid)
INIT_LIST_HEAD(&blkif->pending_free);
INIT_WORK(&blkif->free_work, xen_blkif_deferred_free);
 
-   for (i = 0; i < XEN_BLKIF_REQS; i++) {
+   for (i = 0; i < XEN_MAX_BLKIF_REQS; i++) {
req = kzalloc(sizeof(*req), GFP_KERNEL);
if (!req)
goto fail;
@@ -198,8 +199,8 @@ fail:
return ERR_PTR(-ENOMEM);
 }
 
-static int xen_blkif_map(struct xen_blkif *blkif, grant_ref_t gref,
-unsigned int evtchn)
+static int xen_blkif_map(struct xen_blkif *blkif, grant_ref_t *gref,
+unsigned int nr_grefs, unsigned int evtchn)
 {
int err;
 
@@ -207,7 +208,7 @@ static int xen_blkif_map(struct xen_blkif *blkif, 
grant_ref_t gref,
if (blkif->irq)
return 0;
 
-   err = xenbus_map_ring_valloc(blkif->be->dev, &gref, 1,
+   err = xenbus_map_ring_valloc(blkif->be->dev, gref, nr_gre

[Xen-devel] [PATCH v2 1/2] driver: xen-blkfront: move talk_to_blkback to a more suitable place

[Bob Liu]

The major responsibility of talk_to_blkback() is allocate and initialize
the request ring and write the ring info to xenstore.
But this work should be done after backend entered 'XenbusStateInitWait' as
defined in the protocol file.
See xen/include/public/io/blkif.h in XEN git tree:
FrontBack
==
XenbusStateInitialising  XenbusStateInitialising
 o Query virtual device   o Query backend device identification
   properties.  data.
 o Setup OS device instance.  o Open and validate backend device.
  o Publish backend features and
transport parameters.
 |
 |
 V
 XenbusStateInitWait

o Query backend features and
  transport parameters.
o Allocate and initialize the
  request ring.

There is no problem with this yet, but it is an violation of the design and
furthermore it would not allow frontend/backend to negotiate 'multi-page'
and 'multi-queue' features.

Changes in v2:
 - Re-write the commit message to be more clear.

Signed-off-by: Bob Liu 
Acked-by: Roger Pau Monné 
---
 drivers/block/xen-blkfront.c | 14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 2c61cf8..88e23fd 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -1430,13 +1430,6 @@ static int blkfront_probe(struct xenbus_device *dev,
info->handle = simple_strtoul(strrchr(dev->nodename, '/')+1, NULL, 0);
dev_set_drvdata(&dev->dev, info);
 
-   err = talk_to_blkback(dev, info);
-   if (err) {
-   kfree(info);
-   dev_set_drvdata(&dev->dev, NULL);
-   return err;
-   }
-
return 0;
 }
 
@@ -1906,8 +1899,13 @@ static void blkback_changed(struct xenbus_device *dev,
dev_dbg(&dev->dev, "blkfront:blkback_changed to state %d.\n", 
backend_state);
 
switch (backend_state) {
-   case XenbusStateInitialising:
case XenbusStateInitWait:
+   if (talk_to_blkback(dev, info)) {
+   kfree(info);
+   dev_set_drvdata(&dev->dev, NULL);
+   break;
+   }
+   case XenbusStateInitialising:
case XenbusStateInitialised:
case XenbusStateReconfiguring:
case XenbusStateReconfigured:
-- 
1.8.3.1


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

[Xen-devel] [RFC] xen/arm: Find automatically the gnttab region for DOM0

[Julien Grall]

Currently, the grant table region is hardcoded per-platform. When a new
board is coming up, we have to check the spec in order to find a space
in the memory layout free. Depending on the platform it may be tedious.

A good candidate for the gnttab region is the one used by Xen binary as
some part will never be mapped to the DOM0 address, MMIO are mapped 1:1
and the RAM will be either:
- direct mapped: 1:1 mapping is used => no problem
- non direct mapped: Xen always relocates himself as high as possible
(limited to 4GB on ARM32) and the RAM bank are filled from the first
one. It's very unlikely that the gnttab region will overlap with the
RAM. Although for safety a check may be necessary when we will reenable
the option.

Futhermore, there is plenty of space to contain a big gnttab, the default
size is 32 frame (i.e 32KB) but it can be changed via a command option.

We can only use text section as it will always reside in memory, never be
mapped and the size is big enough (~300KB on ARM64).

Note that on ARM64, the grant table region may be after 4GB (Xen is
relocated to the highest address) using DOM0 32 bit with short page table
may not work. Although, I don't think this is a big deal as device may not
work and/or the RAM is too high due to the 1:1 mapping.

This patch also drop the platforms thunderx and xilinx-zynqmp which became
dummy by dropping the hardcoding DOM0 grant table region.

Signed-off-by: Julien Grall 

---
This patch depends on the patch to use ULL instead of UL for GB [1].

[1] http://lists.xen.org/archives/html/xen-devel/2015-05/msg02972.html
---
 xen/arch/arm/domain_build.c| 46 --
 xen/arch/arm/kernel.h  |  4 +++
 xen/arch/arm/platform.c| 14 ---
 xen/arch/arm/platforms/Makefile|  2 --
 xen/arch/arm/platforms/midway.c|  3 ---
 xen/arch/arm/platforms/omap5.c |  6 -
 xen/arch/arm/platforms/rcar2.c |  3 ---
 xen/arch/arm/platforms/seattle.c   |  3 ---
 xen/arch/arm/platforms/sunxi.c |  3 ---
 xen/arch/arm/platforms/thunderx.c  | 41 --
 xen/arch/arm/platforms/vexpress.c  |  2 --
 xen/arch/arm/platforms/xgene-storm.c   |  3 ---
 xen/arch/arm/platforms/xilinx-zynqmp.c | 41 --
 xen/include/asm-arm/platform.h |  7 --
 14 files changed, 42 insertions(+), 136 deletions(-)
 delete mode 100644 xen/arch/arm/platforms/thunderx.c
 delete mode 100644 xen/arch/arm/platforms/xilinx-zynqmp.c

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 1e545fe..6393886 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -21,6 +21,7 @@
 
 #include 
 #include 
+#include 
 #include "kernel.h"
 
 static unsigned int __initdata opt_dom0_max_vcpus;
@@ -605,8 +606,8 @@ static int make_memory_node(const struct domain *d,
 return res;
 }
 
-static int make_hypervisor_node(struct domain *d,
-void *fdt, const struct dt_device_node *parent)
+static int make_hypervisor_node(const struct kernel_info *kinfo,
+const struct dt_device_node *parent)
 {
 const char compat[] =
 "xen,xen-"__stringify(XEN_VERSION)"."__stringify(XEN_SUBVERSION)"\0"
@@ -615,9 +616,10 @@ static int make_hypervisor_node(struct domain *d,
 gic_interrupt_t intr;
 __be32 *cells;
 int res;
+/* Convenience alias */
 int addrcells = dt_n_addr_cells(parent);
 int sizecells = dt_n_size_cells(parent);
-paddr_t gnttab_start, gnttab_size;
+void *fdt = kinfo->fdt;
 
 DPRINT("Create hypervisor node\n");
 
@@ -639,12 +641,9 @@ static int make_hypervisor_node(struct domain *d,
 if ( res )
 return res;
 
-platform_dom0_gnttab(&gnttab_start, &gnttab_size);
-DPRINT("  Grant table range: %#"PRIpaddr"-%#"PRIpaddr"\n",
-   gnttab_start, gnttab_start + gnttab_size);
 /* reg 0 is grant table space */
 cells = ®[0];
-dt_set_range(&cells, parent, gnttab_start, gnttab_size);
+dt_set_range(&cells, parent, kinfo->gnttab_start, kinfo->gnttab_size);
 res = fdt_property(fdt, "reg", reg,
dt_cells_to_size(addrcells + sizecells));
 if ( res )
@@ -1189,7 +1188,7 @@ static int handle_node(struct domain *d, struct 
kernel_info *kinfo,
 
 if ( node == dt_host )
 {
-res = make_hypervisor_node(d, kinfo->fdt, node);
+res = make_hypervisor_node(kinfo, node);
 if ( res )
 return res;
 
@@ -1365,6 +1364,36 @@ static void evtchn_fixup(struct domain *d, struct 
kernel_info *kinfo)
 panic("Cannot fix up \"interrupts\" property of the hypervisor node");
 }
 
+static void __init find_gnttab_region(struct domain *d,
+  struct kernel_info *kinfo)
+{
+/*
+ * The region used by Xen on the memory will never be mapped in DOM0
+ * memory l

[Xen-devel] [PATCH] xen: Use ULL for GB macro

[Julien Grall]

On 32bit, GB(4) doesn't fit on an unsigned long.

Alos, fix a couple of printf format in x86 which breaks after using
unsigned long long.

Signed-off-by: Julien Grall 
---
 xen/arch/x86/apic.c  | 2 +-
 xen/arch/x86/io_apic.c   | 2 +-
 xen/include/xen/config.h | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/apic.c b/xen/arch/x86/apic.c
index 499e70f..bf0b2fe 100644
--- a/xen/arch/x86/apic.c
+++ b/xen/arch/x86/apic.c
@@ -992,7 +992,7 @@ void __init init_apic_mappings(void)
 apic_phys = mp_lapic_addr;
 
 set_fixmap_nocache(FIX_APIC_BASE, apic_phys);
-apic_printk(APIC_VERBOSE, "mapped APIC to %08lx (%08lx)\n", APIC_BASE,
+apic_printk(APIC_VERBOSE, "mapped APIC to %08llx (%08lx)\n", APIC_BASE,
 apic_phys);
 
 __next:
diff --git a/xen/arch/x86/io_apic.c b/xen/arch/x86/io_apic.c
index 976c0c5..1b2300a 100644
--- a/xen/arch/x86/io_apic.c
+++ b/xen/arch/x86/io_apic.c
@@ -2546,7 +2546,7 @@ void __init init_ioapic_mappings(void)
 clear_page(__va(ioapic_phys));
 }
 set_fixmap_nocache(idx, ioapic_phys);
-apic_printk(APIC_VERBOSE, "mapped IOAPIC to %08lx (%08lx)\n",
+apic_printk(APIC_VERBOSE, "mapped IOAPIC to %08llx (%08lx)\n",
 __fix_to_virt(idx), ioapic_phys);
 idx++;
 
diff --git a/xen/include/xen/config.h b/xen/include/xen/config.h
index 6478a0a..f0746c2 100644
--- a/xen/include/xen/config.h
+++ b/xen/include/xen/config.h
@@ -70,7 +70,7 @@
 #define __bitwise
 
 #define MB(_mb) (_AC(_mb, UL) << 20)
-#define GB(_gb) (_AC(_gb, UL) << 30)
+#define GB(_gb) (_AC(_gb, ULL) << 30)
 
 #define __STR(...) #__VA_ARGS__
 #define STR(...) __STR(__VA_ARGS__)
-- 
2.1.4


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

Re: [Xen-devel] [PATCH v6 1/4] pci: add pci_iomap_wc() variants

[Bjorn Helgaas]

On Wed, May 20, 2015 at 04:08:10PM -0700, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" 
> 
> This allows drivers to take advantage of write-combining
> when possible. The PCI specification does not allow for us
> to automatically identify a memory region which needs
> write-combining so drivers have to identify these areas
> on their own. There is IORESOURCE_PREFETCH but as clarified
> by Michael and confirmed later by Bjorn, PCI prefetch bit
> merely means bridges can combine writes and prefetch reads.
> Prefetch does not affect ordering rules and does not allow
> writes to be collapsed [0]. WC is stronger, it allows collapsing
> and changes ordering rules. WC can also hurt latency as small
> writes are buffered. Because of all this drivers needs to
> know what they are doing, we can't set a write-combining
> preference flag in the pci core automatically for drivers.
> 
> Lastly although there is also arch_phys_wc_add() this makes
> use of architecture specific write-combining *hacks* and
> the only one currently defined and used is MTRR for x86.
> MTRRs are legacy, limited in number, have restrictive size
> constraints, and are known to interact pooly with the BIOS.
> MTRRs should only really be considered on old video framebuffer
> drivers. If we made ioremap_wc() and similar calls start
> automatically adding MTRRs, then performance will vary wildly
> with the order of driver loading because we'll run out of MTRRs
> part-way through bootup.
> 
> There are a few motivations for phasing out of MTRR and
> helping driver change over to use write-combining with PAT:
> 
> a) Take advantage of PAT when available
> 
> b) Help bury MTRR code away, MTRR is architecture specific and on
>x86 its replaced by PAT
> 
> c) Help with the goal of eventually using _PAGE_CACHE_UC over
>_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (see commit
>de33c442e titled "x86 PAT: fix performance drop for glx,
>use UC minus for ioremap(), ioremap_nocache() and
>pci_mmap_page_range()")
> 
> [0] https://lkml.org/lkml/2015/4/21/714

I tentatively put this (and the rest of the series) on a pci/resource
branch.  I'm hoping you'll propose some clarification about
EXPORT_SYMBOL_GPL().

In the meantime, I tried to make the changelog a bit more concise, as
below.  Let me know if I omitted something essential.  We still have URLs
for the discussion for the fine points.

commit 75387ae87b7aebc2a5b447f4d1b8b17a23c15b08
Author: Luis R. Rodriguez 
Date:   Wed May 20 16:08:10 2015 -0700

PCI: Add pci_iomap_wc() variants

PCI BARs tell us whether prefetching is safe, but they don't say anything
about write combining (WC).  WC changes ordering rules and allows writes to
be collapsed, so it's not safe in general to use it on a prefetchable
region.

Add pci_iomap_wc() and pci_iomap_wc_range() so drivers can take advantage
of write combining when they know it's safe.

On architectures that don't fully support WC, e.g., x86 without PAT,
drivers for legacy framebuffers may get some of the benefit by using
arch_phys_wc_add() in addition to pci_iomap_wc().  But arch_phys_wc_add()
is unreliable and should be avoided in general.  On x86, it uses MTRRs,
which are limited in number and size, so the results will vary based on
driver loading order.

The goals of adding pci_iomap_wc() are to:

  - Give drivers an architecture-independent way to use WC so they can stop
using interfaces like mtrr_add() (on x86, pci_iomap_wc() uses PAT when
available)

  - Move toward using _PAGE_CACHE_MODE_UC, not _PAGE_CACHE_MODE_UC_MINUS,
on x86 on ioremap_nocache() (see de33c442ed2a ("x86 PAT: fix
performance drop for glx, use UC minus for ioremap(), ioremap_nocache()
and pci_mmap_page_range()")

[bhelgaas: changelog]
Link: 
http://lkml.kernel.org/r/1426893517-2511-6-git-send-email-mcg...@do-not-panic.com
Original-posting: 
http://lkml.kernel.org/r/1432163293-20965-1-git-send-email-mcg...@do-not-panic.com
Signed-off-by: Luis R. Rodriguez 
Signed-off-by: Bjorn Helgaas 

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

Re: [Xen-devel] [PATCH v6 1/4] pci: add pci_iomap_wc() variants

[Bjorn Helgaas]

On Wed, May 20, 2015 at 04:08:10PM -0700, Luis R. Rodriguez wrote:
> ...
> --- a/lib/pci_iomap.c
> +++ b/lib/pci_iomap.c
> @@ -52,6 +52,46 @@ void __iomem *pci_iomap_range(struct pci_dev *dev,
>  EXPORT_SYMBOL(pci_iomap_range);
>  
>  /**
> + * pci_iomap_wc_range - create a virtual WC mapping cookie for a PCI BAR
> + * @dev: PCI device that owns the BAR
> + * @bar: BAR number
> + * @offset: map memory at the given offset in BAR
> + * @maxlen: max length of the memory to map
> + *
> + * Using this function you will get a __iomem address to your device BAR.
> + * You can access it using ioread*() and iowrite*(). These functions hide
> + * the details if this is a MMIO or PIO address space and will just do what
> + * you expect from them in the correct way. When possible write combining
> + * is used.
> + *
> + * @maxlen specifies the maximum length to map. If you want to get access to
> + * the complete BAR from offset to the end, pass %0 here.
> + * */
> +void __iomem *pci_iomap_wc_range(struct pci_dev *dev,
> +  int bar,
> +  unsigned long offset,
> +  unsigned long maxlen)
> +{
> + resource_size_t start = pci_resource_start(dev, bar);
> + resource_size_t len = pci_resource_len(dev, bar);
> + unsigned long flags = pci_resource_flags(dev, bar);
> +
> + if (len <= offset || !start)
> + return NULL;
> + len -= offset;
> + start += offset;
> + if (maxlen && len > maxlen)
> + len = maxlen;
> + if (flags & IORESOURCE_IO)
> + return NULL;
> + if (flags & IORESOURCE_MEM)
> + return ioremap_wc(start, len);
> + /* What? */
> + return NULL;
> +}
> +EXPORT_SYMBOL_GPL(pci_iomap_wc_range);
> +
> +/**
>   * pci_iomap - create a virtual mapping cookie for a PCI BAR
>   * @dev: PCI device that owns the BAR
>   * @bar: BAR number
> @@ -70,4 +110,25 @@ void __iomem *pci_iomap(struct pci_dev *dev, int bar, 
> unsigned long maxlen)
>   return pci_iomap_range(dev, bar, 0, maxlen);
>  }
>  EXPORT_SYMBOL(pci_iomap);
> +
> +/**
> + * pci_iomap_wc - create a virtual WC mapping cookie for a PCI BAR
> + * @dev: PCI device that owns the BAR
> + * @bar: BAR number
> + * @maxlen: length of the memory to map
> + *
> + * Using this function you will get a __iomem address to your device BAR.
> + * You can access it using ioread*() and iowrite*(). These functions hide
> + * the details if this is a MMIO or PIO address space and will just do what
> + * you expect from them in the correct way. When possible write combining
> + * is used.
> + *
> + * @maxlen specifies the maximum length to map. If you want to get access to
> + * the complete BAR without checking for its length first, pass %0 here.
> + * */
> +void __iomem *pci_iomap_wc(struct pci_dev *dev, int bar, unsigned long 
> maxlen)
> +{
> + return pci_iomap_wc_range(dev, bar, 0, maxlen);
> +}
> +EXPORT_SYMBOL_GPL(pci_iomap_wc);

Huh.  So you let me talk about marking the unused pcim_iomap_wc()
EXPORT_SYMBOL_GPL(), but didn't remind me that you also proposed to mark
the symbol you really care about, the one you already have a use for, as
EXPORT_SYMBOL_GPL().  Sigh.

In my opinion, if we're going to use EXPORT_SYMBOL_GPL() at all, we should
use it consistently and based on technical considerations.  I base this on
statements like the following:

  - "[EXPORT_SYMBOL_GPL()] implies that the function is considered an
internal implementation issue, and not really an interface." [Rusty
Russell, 1]

  - "... using the xxx_GPL() version to show that it's an internal
interface ..." [Linus Torvalds, 2]

  - "Anything exported via EXPORT_SYMBOL_GPL() is considered by the author
to be so fundamental to the kernel that using it would be impossible
without creating a derivative work." [Matthew Garrett, 3]

  - "Linus's initial point for [_GPL symbols] has been so diluted by random
lobby groups asking for every symbol to be _GPL that they are becoming
effectively pointless now." [Dave Airlie, 4]

Existing interfaces like these are exported with EXPORT_SYMBOL():

  ioremap()
  ioremap_wc()
  ioremap_prot()
  pci_iomap()
  pci_map_rom()

I would argue that pci_iomap_wc() is similar in spirit and is no more an
internal implementation issue than they are, and should be exported
similarly.

So my *advice* is to use EXPORT_SYMBOL() in this case, because that's a
choice you can defend on technical grounds.  I think it's hard to argue
that pci_iomap_wc() is so fundamental or unique to Linux that a caller
would automatically be a derivative work.

Will I still merge it as EXPORT_SYMBOL_GPL()?  Maybe.  I don't feel *good*
about it because the only explanation I can give is "the author wanted it
that way," and that's unsatisfying.  But I did already ack it (before I
noticed the _GPL() issue), and I won't try to retract that and prevent
somebody else from merging it.  And maybe your proposal to clarify th

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

[osstest service user]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-freebsd10-amd64 10 guest-startfail REGR. vs. 56831

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-libvirt  11 guest-start  fail   like 56831
 test-amd64-amd64-libvirt 11 guest-start  fail   like 56831

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-xsm  11 guest-start  fail   never pass
 test-amd64-amd64-xl-xsm  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail never 
pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail never 
pass
 test-amd64-amd64-libvirt-xsm 11 guest-start  fail   never pass
 test-amd64-i386-xl-xsm   11 guest-start  fail   never pass
 test-armhf-armhf-xl-xsm  11 guest-start  fail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-sedf 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-sedf-pin 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 11 guest-start  fail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass

version targeted for testing:
 qemuu9e549d36e989b14423279fb991b71728a2a4ae7c
baseline version:
 qemuueba05e922e8e7f307bc5d4104a78797e55124e97


People who touched revisions under test:
  Cole Robinson 
  Daniel P. Berrange 
  Gerd Hoffmann 
  Ján Tomko 
  Peter Maydell 


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
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmfail
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm fail
 test-amd64-amd64-libvirt-xsm fail
 test-armhf-armhf-libvirt-xsm fail
 test-amd64-i386-libvirt-xsm  fail
 test-amd64-amd64-xl-xsm  fail
 test-armhf-armhf-xl-xsm  fail
 test-amd64-i386-xl-xsm   fail
 test-amd64-amd64-xl-pvh-amd  fail
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  fail
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-armhf-armhf-xl-arndale  pass
 test-amd64-amd64-xl-credit2  pass
 test-armhf-armhf-xl-credit2  pass
 test-armhf-armhf-xl-cubietruck 

[Xen-devel] [xen-4.5-testing test] 56898: regressions - FAIL

[osstest service user]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail REGR. vs. 56728
 test-amd64-amd64-rumpuserxen-amd64 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail REGR. vs. 56728

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop  fail pass in 56821

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 56728

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-sedf-pin 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-sedf 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  ddfe333aef87e6c5f52b84c8beb3277be4663313
baseline version:
 xen  0c4e0ef608c98abef6220b0b027d9ce8ec65fd5f


People who touched revisions under test:
  Eugene Korenevsky 
  Jan Beulich 
  Paul Durrant 
  Ross Lagerwall 
  Suravee Suthikulpanit 


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

Re: [Xen-devel] [PATCH v6 2/2] kconfig: add xenconfig defconfig helper

[Luis R. Rodriguez]

On Thu, May 21, 2015 at 11:49:17PM +0900, Masahiro Yamada wrote:
> Hi,
> 
> I am not familiar with xen at all, just some comments
> from the build system side.
> 
> 
> 
> 2015-05-21 3:53 GMT+09:00 Luis R. Rodriguez :
> > From: "Luis R. Rodriguez" 
> >
> > This lets you build a kernel which can support xen dom0
> > or xen guests on i386, x86-64 and arm64 by just using:
> >
> >make xenconfig
> >
> > You can start from an allnoconfig and then switch to xenconfig.
> > This also splits out the options which are available currently
> > to be built with x86 and 'make ARCH=arm64' under a shared config.
> >
> > Technically xen supports a dom0 kernel and also a guest
> > kernel configuration but upon review with the xen team
> > since we don't have many dom0 options its best to just
> > combine these two into one.
> >
> > A few generic notes: we enable both of these:
> >
> > CONFIG_INET=y
> > CONFIG_BINFMT_ELF=y
> >
> > although technically not required given you likely will
> > end up with a pretty useless system otherwise.
> >
> > A few architectural differences worth noting:
> >
> > $ make allnoconfig; make xenconfig > /dev/null ; \
> > grep XEN .config > 64-bit-config
> > $ make ARCH=i386 allnoconfig; make ARCH=i386 xenconfig > /dev/null; \
> > grep XEN .config > 32-bit-config
> > $ make ARCH=arm64 allnoconfig; make ARCH=arm64 xenconfig > /dev/null; \
> > grep XEN .config > arm64-config
> >
> > Since the options are already split up with a generic config and
> > architecture specific configs you anything on the x86 configs
> > are known to only work right now on x86. For instance arm64 doesn't
> > support MEMORY_HOTPLUG yet as such although we try to enabe it
> > generically arm64 doesn't have it yet, so we leave the xen
> > specific kconfig option XEN_BALLOON_MEMORY_HOTPLUG on x86's config
> > file to set expecations correctly.
> >
> > Then on x86 we have differences between i386 and x86-64. The difference
> > between 64-bit-config and 32-bit-config is you don't get XEN_MCE_LOG as
> > this is only supported on 64-bit. You also do not get on i386
> > XEN_BALLOON_MEMORY_HOTPLUG, there does not seem to be any technical
> > reasons to not allow this but I gave up after a few attempts.
> >
> > Cc: Josh Triplett 
> > Cc: Borislav Petkov 
> > Cc: Pekka Enberg 
> > Cc: David Rientjes 
> > Cc: Michal Marek 
> > Cc: Randy Dunlap 
> > Cc: penb...@kernel.org
> > Cc: levinsasha...@gmail.com
> > Cc: mtosa...@redhat.com
> > Cc: fengguang...@intel.com
> > Cc: David Vrabel 
> > Cc: Ian Campbell 
> > Cc: Konrad Rzeszutek Wilk 
> > Cc: xen-de...@lists.xenproject.org
> > Acked-by: Stefano Stabellini 
> > Acked-by: Julien Grall 
> > Acked-by: Michal Marek 
> > Acked-by: David Rientjes 
> > Reviewed-by: Josh Triplett 
> > Signed-off-by: Luis R. Rodriguez 
> > ---
> 
> > diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
> > index 6950032..f52abae 100644
> > --- a/scripts/kconfig/Makefile
> > +++ b/scripts/kconfig/Makefile
> > @@ -115,6 +115,10 @@ PHONY += kvmconfig
> >  kvmconfig: kvm_guest.config
> > @:
> >
> > +PHONY += xenconfig
> > +xenconfig: xen.config
> > +   @:
> > +
> >  PHONY += tinyconfig
> >  tinyconfig:
> > $(Q)$(MAKE) -f $(srctree)/Makefile allnoconfig tiny.config
> 
> 
> "make xenconfig" is equivalent to "make xen.config"
> and only saves one character.
> 
> Now we have only three targets for mergeconfig (tiny, kvm, xen),
> so it is OK to add this as an alias.
> But if we have more such targets, we might have
> to consider to use generic targets (*.config) at some point.

I'm frankly terrified of all these config target options growing more and
the possible large collateral of patches to Kconfig files in the future. Since
this is a small specialized group now, I think we should treat it as such but
I think what you say has good merit long run.

For now I'm more of a fan we limit what we stuff in here and if this explodes
then only have new options use the subject.config target. Thoughts?

> I do not intend to block this.
> Just take my comment with a grain of salt..
> 
> 
> > @@ -140,6 +144,7 @@ help:
> > @echo  '  listnewconfig   - List new options'
> > @echo  '  olddefconfig- Same as silentoldconfig but sets new 
> > symbols to their default value'
> > @echo  '  kvmconfig   - Enable additional options for kvm guest 
> > kernel support'
> > +   @echo  '  xenconfig   - Enable additional options for xen dom0 
> > and guest kernel support'
> > @echo  '  tinyconfig  - Configure the tiniest possible kernel'
> >
> >  # lxdialog stuff
> 
> 
> If kvmconfig and xenconfig are only available for x86,
> is it better to enclose those helps with
> ifeq ($(ARCH),x86)
>  ...
> endif

That's true if kvm was only for x86 but it is not, and likewise for xen.

mcgrof@ergon ~/linux-next (git::sumadre)$ git grep "config KVM$"
arch/arm/kvm/Kconfig:config KVM
arch/arm64/kvm/Kconfig:config KVM
arch/mips/kvm/Kconfig:config KVM
arc

Re: [Xen-devel] "swiotlb buffer is full" problem with tg3 and kernel 3.16.0-4-686-pae on Xen 4.4.1

[Ian Campbell]

On Thu, 2015-05-21 at 17:17 +0200, Marco Steinacher wrote:
> Shall I try to build a 3.16.0-4-686-pae kernel with
> "CONFIG_NEED_DMA_MAP_STATE=y"?

Yes, this is what I would recommend. Although it's not as simple as
turning it on, you actually need to patch the Kconfig as in this mail:
http://www.spinics.net/lists/netdev/msg325844.html such that it comes on
by itself.

> Shall I try to set the 'iommu' and/or 'swiotlb' kernel parameters? To
> what values?

I don't think so, those were used in that thread to demonstrate that the
issue exited even on native -- i.e. not under Xen

If you could file your results into the Debian BTW[0], i.e. by running
"reportbug " then that would be useful to help get
it fixed in a future update.

Ian.

[0] http://bugs.debian.org 


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

Re: [Xen-devel] [PATCH] xl: Support (by ignoring) xl migrate --live

[Ian Campbell]

On Thu, 2015-05-21 at 19:44 +0200, Olaf Hering wrote:
> On Thu, May 21, Ian Campbell wrote:
> 
> > My pod2text doesn't seem to complain, but does this help?
> 
> Yes, this fixes it.

Pushed, thanks.

OOI what version of pod2text are you both using which exposes this?

Ian.


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

Re: [Xen-devel] [PATCH v6 0/2] kconfig: add xenconfig

[Luis R. Rodriguez]

On Thu, May 21, 2015 at 04:20:27PM +0800, Michal Marek wrote:
> Dne 21.5.2015 v 02:53 Luis R. Rodriguez napsal(a):
> > From: "Luis R. Rodriguez" 
> > 
> > Michal Marek, Xen folks (David Vrabel, Konrad, Ian), which tree should
> > these go through?
> 
> Not kbuild, if I may ask :). Otherwise people will find me in
> get_maintainer.pl output and keep CCing me on updates to the xen.config
> files, which is something I am not at all familiar with.

As you wish :)

  Luis

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

Re: [Xen-devel] [PATCH] xl: Support (by ignoring) xl migrate --live

[Andrew Cooper]

On 21/05/15 17:34, Ian Campbell wrote:
> On Thu, 2015-05-21 at 18:23 +0200, Olaf Hering wrote:
>> On Thu, May 21, Ian Campbell wrote:
>>
>>> On Thu, 2015-05-14 at 15:05 +0100, Ian Campbell wrote:
 On Thu, 2015-05-14 at 13:41 +0100, Ian Jackson wrote:
> xm migrate would do non-live migration (effectively, save, transfer
> and restore) by default, unless you specified --live.
>
> xl migrate always does live migration.  Honour (by ignoring) --live
> for compatibility with old callers.  Document this.
>
> (This patch should be backported as far as possible.)
>
> Reported-by: Matthew Vernon 
> Signed-off-by: Ian Jackson 
> CC: Matthew Vernon 
 Acked-by: Ian Campbell 
>>> Applied, thanks.
>> I think this causes a build failure, somewhere introduced here:
>>
>> git log -p -M --stat e13013d..upstream/staging -- docs/man/
>>
>> [  146s] man/xl.pod.1 around line 1529: '=item' outside of any '=over'
>> [  146s] man/xl.pod.1 around line 1531: You forgot a '=back' before '=head1'
>> [  146s] POD document had syntax errors at /usr/bin/pod2text line 84.
>> [  146s] Makefile:167: recipe for target 'txt/man/xl.1.txt' failed
>> [  146s] make[1]: *** [txt/man/xl.1.txt] Error 255
> My pod2text doesn't seem to complain, but does this help?
>
> -8>---
>
> From 5da86305c378482ab2f6359375bd1b63ddc51102 Mon Sep 17 00:00:00 2001
> From: Ian Campbell 
> Date: Thu, 21 May 2015 17:31:39 +0100
> Subject: [PATCH] docs: correct pod syntax
>
> Olaf reports:
> [  146s] man/xl.pod.1 around line 1529: '=item' outside of any '=over'
> [  146s] man/xl.pod.1 around line 1531: You forgot a '=back' before '=head1'
> [  146s] POD document had syntax errors at /usr/bin/pod2text line 84.
> [  146s] Makefile:167: recipe for target 'txt/man/xl.1.txt' failed
> [  146s] make[1]: *** [txt/man/xl.1.txt] Error 255
>
> Reported-by: Olaf Hering 
> Signed-off-by: Ian Campbell 

This happens to be exactly the same patch as I debugged into existence
when attempting to fix this issue myself.

Tested-by: Andrew Cooper 

> ---
>  docs/man/xl.pod.1 |4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
> index b2bc362..4eb929d 100644
> --- a/docs/man/xl.pod.1
> +++ b/docs/man/xl.pod.1
> @@ -1526,8 +1526,12 @@ xl is mostly command-line compatible with the old xm 
> utility used with
>  the old Python xend.  For compatibility, the following options are
>  ignored:
>  
> +=over 4
> +
>  =item B
>  
> +=back
> +
>  =head1 TO BE DOCUMENTED
>  
>  We need better documentation for:


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

Re: [Xen-devel] [PATCH] xl: Support (by ignoring) xl migrate --live

[Andrew Cooper]

On 21/05/15 19:02, Ian Campbell wrote:
> On Thu, 2015-05-21 at 19:44 +0200, Olaf Hering wrote:
>> On Thu, May 21, Ian Campbell wrote:
>>
>>> My pod2text doesn't seem to complain, but does this help?
>> Yes, this fixes it.
> Pushed, thanks.
>
> OOI what version of pod2text are you both using which exposes this?
>
> Ian.
>

In my case it was pod2man, but it turns out that working out the version
is hard.

bash-4.2$ pod2man --version
Unknown option: version
bash-4.2$ pod2man -V
Unknown option: V

The best the manpage has to offer is

"The current version of this script is always available from its web
site at .  It is also
part of the Perl core distribution as of 5.6.0."

It is whatever comes as standard in CentOS 7.

~Andrew

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

Re: [Xen-devel] [PATCH RFC v1] libxl: Introduce a template for devices with a controller

[George Dunlap]

On 05/21/2015 06:07 PM, George Dunlap wrote:
> We have several outstanding patch series which add devices that have
> two levels: a controller and individual devices attached to that
> controller.
> 
> In the interest of consistency, this patch introduces a section that
> sketches out a template for interfaces for such devices.
> 
> Signed-off-by: George Dunlap 
> ---
> CC: Ian Campbell 
> CC: Ian Jackson 
> CC: Wei Liu 
> CC: Juergen Gross 
> CC: Chun Yan Liu 
> CC: Olaf Hering 
> 
> So, this is definitely RFC -- I tried to spec things out in a way that
> made sense, but I often just chose something that I thought would be a
> sensible starting point for discussion.
> 
> This spec looks a lot more like the PVUSB spec than the PVSCSI spec,
> in part because I think the PVUSB spec has already had a lot more
> thought that's gone into it.
> 
> A couple of random points to discuss:
> 
> * Calling things "controllers", using ctrl for the device name,
>   and using "ctrl" as the field name for the devid of the controller
>   in the individual devices.
> 
> * I've said that having an index (port, lun, whatever) is optional.
>   Do we want to make that requred?  Do we want it to have a consistent
>   name?  In the case of emulated USB, we can't really specify to qemu
>   what port the device gets attached to, so I'm tempted to say it's
>   not required; but even there we could always give it a port number
>   just for name's sake.
> 
> * Naming sub-devices.  We need to have a way to uniquely name both
>   controllers and subdevices.  Here I've said that we will have both
>   ctrl and  devid namespaces, mainly because in the
>   previous point I opted not to require an index.  Another option
>   would be not to have another devid namespace, but to use
>as the unique identifier.  (This would mean requiring
>   the index/port/lun specification above.)
> 
> * libxl_device__list listing devices across all controllers.  I
>   think this is the most practical thing to do, but one could imagine
>   wanting to query by controller ID instead.
> 
> Feedback welcome.
> ---
>  tools/libxl/libxl.h | 46 ++
>  1 file changed, 46 insertions(+)
> 
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index 2ed7194..d757845 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -1234,6 +1234,52 @@ void libxl_vtpminfo_list_free(libxl_vtpminfo *, int 
> nr_vtpms);
>   *
>   *   This function does not interact with the guest and therefore
>   *   cannot block on the guest.
> + *
> + * Controllers
> + * ---
> + *
> + * Most devices are treated individually.  Some devices however, like
> + * USB or SCSI, inherently have the need to have "busses" or
> + * "controllers" to which individual devices can be attached.
> + *
> + * In that case, for each , there will be two sets of the
> + * functions, types, and devid namespaces outlined above: one based on
> + * '', and one based on 'ctrl'.
> + *
> + * In those cases, libxl_device_ctrl_ will act more or
> + * less like top-level non-bus devices: they will either create or
> + * accept a libxl_devid which will be unique within the
> + * ctrl libxl_devid namespace.
> + *
> + * Second-level devices which will be attached to a controller will
> + * include in their libxl_device_ a field called ctrl, which
> + * will be the libxl_devid of the corresponding controller.  It may also
> + * include an index onto that bus, that represents (for example) a USB
> + * port or a SCSI LUN.
> + *
> + * These second-level devices will also have their own devid which
> + * will be unique within the  devid namespace, and will be used
> + * for queries or removals.
> + *
> + * In the case where there are multiple different ways to implement a
> + * given device -- for instance, one which is fully PV and one which
> + * uses an emulator -- the controller will contain a field which
> + * specifies what type of implementation is used.  The implementations
> + * of individual devices will be known by the controller to which they are
> + * attached.
> + *
> + * If libxl_device__add receives an uninitialized ctrl devid, it
> + * may return an error.  Or it may (but is not required to) choose to
> + * automatically choose a suitable controller to which to attach the
> + * new device.  It may also (but is not required to) automatically
> + * create a new controller if no suitable controllers exist.
> + * Individual devices should document their behavior.
> + *
> + * libxl_device_ctrl_list will list all controllers for the domain.
> + *
> + * libxl_device__list will list all devices for all controllers
> + * for the domain.  The individual libxl_device_ will include
> + * the devid of the controller to which it is attached.

Hmm, I also meant to add:

---
For each type, the domain config file will contain a single list of
controllers, and a single list of devices.  libxl will first iterate
through the list adding the controlllers, then iterate throu

[Xen-devel] [PATCH RFC v1] libxl: Introduce a template for devices with a controller

[George Dunlap]

We have several outstanding patch series which add devices that have
two levels: a controller and individual devices attached to that
controller.

In the interest of consistency, this patch introduces a section that
sketches out a template for interfaces for such devices.

Signed-off-by: George Dunlap 
---
CC: Ian Campbell 
CC: Ian Jackson 
CC: Wei Liu 
CC: Juergen Gross 
CC: Chun Yan Liu 
CC: Olaf Hering 

So, this is definitely RFC -- I tried to spec things out in a way that
made sense, but I often just chose something that I thought would be a
sensible starting point for discussion.

This spec looks a lot more like the PVUSB spec than the PVSCSI spec,
in part because I think the PVUSB spec has already had a lot more
thought that's gone into it.

A couple of random points to discuss:

* Calling things "controllers", using ctrl for the device name,
  and using "ctrl" as the field name for the devid of the controller
  in the individual devices.

* I've said that having an index (port, lun, whatever) is optional.
  Do we want to make that requred?  Do we want it to have a consistent
  name?  In the case of emulated USB, we can't really specify to qemu
  what port the device gets attached to, so I'm tempted to say it's
  not required; but even there we could always give it a port number
  just for name's sake.

* Naming sub-devices.  We need to have a way to uniquely name both
  controllers and subdevices.  Here I've said that we will have both
  ctrl and  devid namespaces, mainly because in the
  previous point I opted not to require an index.  Another option
  would be not to have another devid namespace, but to use
   as the unique identifier.  (This would mean requiring
  the index/port/lun specification above.)

* libxl_device__list listing devices across all controllers.  I
  think this is the most practical thing to do, but one could imagine
  wanting to query by controller ID instead.

Feedback welcome.
---
 tools/libxl/libxl.h | 46 ++
 1 file changed, 46 insertions(+)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 2ed7194..d757845 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -1234,6 +1234,52 @@ void libxl_vtpminfo_list_free(libxl_vtpminfo *, int 
nr_vtpms);
  *
  *   This function does not interact with the guest and therefore
  *   cannot block on the guest.
+ *
+ * Controllers
+ * ---
+ *
+ * Most devices are treated individually.  Some devices however, like
+ * USB or SCSI, inherently have the need to have "busses" or
+ * "controllers" to which individual devices can be attached.
+ *
+ * In that case, for each , there will be two sets of the
+ * functions, types, and devid namespaces outlined above: one based on
+ * '', and one based on 'ctrl'.
+ *
+ * In those cases, libxl_device_ctrl_ will act more or
+ * less like top-level non-bus devices: they will either create or
+ * accept a libxl_devid which will be unique within the
+ * ctrl libxl_devid namespace.
+ *
+ * Second-level devices which will be attached to a controller will
+ * include in their libxl_device_ a field called ctrl, which
+ * will be the libxl_devid of the corresponding controller.  It may also
+ * include an index onto that bus, that represents (for example) a USB
+ * port or a SCSI LUN.
+ *
+ * These second-level devices will also have their own devid which
+ * will be unique within the  devid namespace, and will be used
+ * for queries or removals.
+ *
+ * In the case where there are multiple different ways to implement a
+ * given device -- for instance, one which is fully PV and one which
+ * uses an emulator -- the controller will contain a field which
+ * specifies what type of implementation is used.  The implementations
+ * of individual devices will be known by the controller to which they are
+ * attached.
+ *
+ * If libxl_device__add receives an uninitialized ctrl devid, it
+ * may return an error.  Or it may (but is not required to) choose to
+ * automatically choose a suitable controller to which to attach the
+ * new device.  It may also (but is not required to) automatically
+ * create a new controller if no suitable controllers exist.
+ * Individual devices should document their behavior.
+ *
+ * libxl_device_ctrl_list will list all controllers for the domain.
+ *
+ * libxl_device__list will list all devices for all controllers
+ * for the domain.  The individual libxl_device_ will include
+ * the devid of the controller to which it is attached.
  */
 
 /* Disks */
-- 
1.9.1


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

[Xen-devel] [PATCH v22 02/14] x86/VPMU: Add public xenpmu.h

[Boris Ostrovsky]

Add pmu.h header files, move various macros and structures that will be
shared between hypervisor and PV guests to it.

Move MSR banks out of architectural PMU structures to allow for larger sizes
in the future. The banks are allocated immediately after the context and
PMU structures store offsets to them.

While making these updates, also:
* Remove unused vpmu_domain() macro from vpmu.h
* Convert msraddr_to_bitpos() into an inline and make it a little faster by
  realizing that all Intel's PMU-related MSRs are in the lower MSR range.

Signed-off-by: Boris Ostrovsky 
Acked-by: Kevin Tian 
---
Changes in v22:
* Clarified comments in public header files describing access permissions for
  shared fields


 xen/arch/x86/hvm/svm/vpmu.c  |  83 +++--
 xen/arch/x86/hvm/vmx/vpmu_core2.c| 123 +--
 xen/arch/x86/hvm/vpmu.c  |   8 ++
 xen/arch/x86/oprofile/op_model_ppro.c|   6 +-
 xen/include/Makefile |   3 +-
 xen/include/asm-x86/hvm/vmx/vpmu_core2.h |  32 
 xen/include/asm-x86/hvm/vpmu.h   |  16 ++--
 xen/include/public/arch-arm.h|   5 ++
 xen/include/public/arch-x86/pmu.h| 122 ++
 xen/include/public/pmu.h |  58 +++
 xen/include/xlat.lst |   6 ++
 11 files changed, 328 insertions(+), 134 deletions(-)
 delete mode 100644 xen/include/asm-x86/hvm/vmx/vpmu_core2.h
 create mode 100644 xen/include/public/arch-x86/pmu.h
 create mode 100644 xen/include/public/pmu.h

diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index 6764070..a8b79df 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -30,10 +30,7 @@
 #include 
 #include 
 #include 
-
-#define F10H_NUM_COUNTERS 4
-#define F15H_NUM_COUNTERS 6
-#define MAX_NUM_COUNTERS F15H_NUM_COUNTERS
+#include 
 
 #define MSR_F10H_EVNTSEL_GO_SHIFT   40
 #define MSR_F10H_EVNTSEL_EN_SHIFT   22
@@ -49,6 +46,9 @@ static const u32 __read_mostly *counters;
 static const u32 __read_mostly *ctrls;
 static bool_t __read_mostly k7_counters_mirrored;
 
+#define F10H_NUM_COUNTERS   4
+#define F15H_NUM_COUNTERS   6
+
 /* PMU Counter MSRs. */
 static const u32 AMD_F10H_COUNTERS[] = {
 MSR_K7_PERFCTR0,
@@ -83,12 +83,14 @@ static const u32 AMD_F15H_CTRLS[] = {
 MSR_AMD_FAM15H_EVNTSEL5
 };
 
-/* storage for context switching */
-struct amd_vpmu_context {
-u64 counters[MAX_NUM_COUNTERS];
-u64 ctrls[MAX_NUM_COUNTERS];
-bool_t msr_bitmap_set;
-};
+/* Use private context as a flag for MSR bitmap */
+#define msr_bitmap_on(vpmu)do {\
+   (vpmu)->priv_context = (void *)-1L; \
+   } while (0)
+#define msr_bitmap_off(vpmu)   do {\
+   (vpmu)->priv_context = NULL;\
+   } while (0)
+#define is_msr_bitmap_on(vpmu) ((vpmu)->priv_context != NULL)
 
 static inline int get_pmu_reg_type(u32 addr)
 {
@@ -142,7 +144,6 @@ static void amd_vpmu_set_msr_bitmap(struct vcpu *v)
 {
 unsigned int i;
 struct vpmu_struct *vpmu = vcpu_vpmu(v);
-struct amd_vpmu_context *ctxt = vpmu->context;
 
 for ( i = 0; i < num_counters; i++ )
 {
@@ -150,14 +151,13 @@ static void amd_vpmu_set_msr_bitmap(struct vcpu *v)
 svm_intercept_msr(v, ctrls[i], MSR_INTERCEPT_WRITE);
 }
 
-ctxt->msr_bitmap_set = 1;
+msr_bitmap_on(vpmu);
 }
 
 static void amd_vpmu_unset_msr_bitmap(struct vcpu *v)
 {
 unsigned int i;
 struct vpmu_struct *vpmu = vcpu_vpmu(v);
-struct amd_vpmu_context *ctxt = vpmu->context;
 
 for ( i = 0; i < num_counters; i++ )
 {
@@ -165,7 +165,7 @@ static void amd_vpmu_unset_msr_bitmap(struct vcpu *v)
 svm_intercept_msr(v, ctrls[i], MSR_INTERCEPT_RW);
 }
 
-ctxt->msr_bitmap_set = 0;
+msr_bitmap_off(vpmu);
 }
 
 static int amd_vpmu_do_interrupt(struct cpu_user_regs *regs)
@@ -177,19 +177,22 @@ static inline void context_load(struct vcpu *v)
 {
 unsigned int i;
 struct vpmu_struct *vpmu = vcpu_vpmu(v);
-struct amd_vpmu_context *ctxt = vpmu->context;
+struct xen_pmu_amd_ctxt *ctxt = vpmu->context;
+uint64_t *counter_regs = vpmu_reg_pointer(ctxt, counters);
+uint64_t *ctrl_regs = vpmu_reg_pointer(ctxt, ctrls);
 
 for ( i = 0; i < num_counters; i++ )
 {
-wrmsrl(counters[i], ctxt->counters[i]);
-wrmsrl(ctrls[i], ctxt->ctrls[i]);
+wrmsrl(counters[i], counter_regs[i]);
+wrmsrl(ctrls[i], ctrl_regs[i]);
 }
 }
 
 static void amd_vpmu_load(struct vcpu *v)
 {
 struct vpmu_struct *vpmu = vcpu_vpmu(v);
-struct amd_vpmu_context *ctxt = vpmu->context;
+struct xen_pmu_amd_ctxt *ctxt = vpmu->context;
+uint64_t *ctrl_regs = vpmu_reg_pointer(ctxt, ctrls);
 
 vpmu_reset(vpmu, VPMU_FROZEN);
 
@@ -198,7 +201,7 @@ static vo

[Xen-devel] [PATCH v22 01/14] common/symbols: Export hypervisor symbols to privileged guest

[Boris Ostrovsky]

Export Xen's symbols as {} triplet via new XENPF_get_symbol
hypercall

Signed-off-by: Boris Ostrovsky 
Acked-by: Daniel De Graaf 
Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Dietmar Hahn 
Tested-by: Dietmar Hahn 
---
 xen/arch/x86/platform_hypercall.c   | 28 +++
 xen/common/symbols.c| 54 +
 xen/include/public/platform.h   | 19 +
 xen/include/xen/symbols.h   |  3 +++
 xen/include/xlat.lst|  1 +
 xen/xsm/flask/hooks.c   |  4 +++
 xen/xsm/flask/policy/access_vectors |  2 ++
 7 files changed, 111 insertions(+)

diff --git a/xen/arch/x86/platform_hypercall.c 
b/xen/arch/x86/platform_hypercall.c
index 334d474..7626261 100644
--- a/xen/arch/x86/platform_hypercall.c
+++ b/xen/arch/x86/platform_hypercall.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -798,6 +799,33 @@ ret_t 
do_platform_op(XEN_GUEST_HANDLE_PARAM(xen_platform_op_t) u_xenpf_op)
 }
 break;
 
+case XENPF_get_symbol:
+{
+static char name[KSYM_NAME_LEN + 1]; /* protected by xenpf_lock */
+XEN_GUEST_HANDLE(char) nameh;
+uint32_t namelen, copylen;
+
+guest_from_compat_handle(nameh, op->u.symdata.name);
+
+ret = xensyms_read(&op->u.symdata.symnum, &op->u.symdata.type,
+   &op->u.symdata.address, name);
+
+namelen = strlen(name) + 1;
+
+if ( namelen > op->u.symdata.namelen )
+copylen = op->u.symdata.namelen;
+else
+copylen = namelen;
+
+op->u.symdata.namelen = namelen;
+
+if ( !ret && copy_to_guest(nameh, name, copylen) )
+ret = -EFAULT;
+if ( !ret && __copy_field_to_guest(u_xenpf_op, op, u.symdata) )
+ret = -EFAULT;
+}
+break;
+
 default:
 ret = -ENOSYS;
 break;
diff --git a/xen/common/symbols.c b/xen/common/symbols.c
index fc7c9e7..a59c59d 100644
--- a/xen/common/symbols.c
+++ b/xen/common/symbols.c
@@ -17,6 +17,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #ifdef SYMBOLS_ORIGIN
 extern const unsigned int symbols_offsets[];
@@ -148,3 +150,55 @@ const char *symbols_lookup(unsigned long addr,
 *offset = addr - symbols_address(low);
 return namebuf;
 }
+
+/*
+ * Get symbol type information. This is encoded as a single char at the
+ * beginning of the symbol name.
+ */
+static char symbols_get_symbol_type(unsigned int off)
+{
+/*
+ * Get just the first code, look it up in the token table,
+ * and return the first char from this token.
+ */
+return symbols_token_table[symbols_token_index[symbols_names[off + 1]]];
+}
+
+int xensyms_read(uint32_t *symnum, char *type,
+ uint64_t *address, char *name)
+{
+/*
+ * Symbols are most likely accessed sequentially so we remember position
+ * from previous read. This can help us avoid the extra call to
+ * get_symbol_offset().
+ */
+static uint64_t next_symbol, next_offset;
+static DEFINE_SPINLOCK(symbols_mutex);
+
+if ( *symnum > symbols_num_syms )
+return -ERANGE;
+if ( *symnum == symbols_num_syms )
+{
+/* No more symbols */
+name[0] = '\0';
+return 0;
+}
+
+spin_lock(&symbols_mutex);
+
+if ( *symnum == 0 )
+next_offset = next_symbol = 0;
+if ( next_symbol != *symnum )
+/* Non-sequential access */
+next_offset = get_symbol_offset(*symnum);
+
+*type = symbols_get_symbol_type(next_offset);
+next_offset = symbols_expand_symbol(next_offset, name);
+*address = symbols_address(*symnum);
+
+next_symbol = ++*symnum;
+
+spin_unlock(&symbols_mutex);
+
+return 0;
+}
diff --git a/xen/include/public/platform.h b/xen/include/public/platform.h
index 82ec84e..1e6a6ce 100644
--- a/xen/include/public/platform.h
+++ b/xen/include/public/platform.h
@@ -590,6 +590,24 @@ struct xenpf_resource_op {
 typedef struct xenpf_resource_op xenpf_resource_op_t;
 DEFINE_XEN_GUEST_HANDLE(xenpf_resource_op_t);
 
+#define XENPF_get_symbol   63
+struct xenpf_symdata {
+/* IN/OUT variables */
+uint32_t namelen; /* IN:  size of name buffer   */
+  /* OUT: strlen(name) of hypervisor symbol (may be */
+  /*  larger than what's been copied to guest)  */
+uint32_t symnum;  /* IN:  Symbol to read*/
+  /* OUT: Next available symbol. If same as IN then */
+  /*  we reached the end*/
+
+/* OUT variables */
+XEN_GUEST_HANDLE(char) name;
+uint64_t address;
+char type;
+};
+typedef struct xenpf_symdata xenpf_symdata_t;
+DEFINE_XEN_GUEST_HANDLE(xenpf_symdata_t);
+
 /*
  * ` enum neg_errnoval
  * ` HYPERVISOR_platform_op(const struct xen_platform_op*);
@@ -619,6 +637,7 @@ struct xen_platform_op {
 struct xenpf_m

[Xen-devel] [PATCH v22 12/14] x86/VPMU: Merge vpmu_rdmsr and vpmu_wrmsr

[Boris Ostrovsky]

The two routines share most of their logic.

Signed-off-by: Boris Ostrovsky 
Reviewed-by: Dietmar Hahn 
---
 xen/arch/x86/hvm/vpmu.c| 75 --
 xen/include/asm-x86/hvm/vpmu.h | 14 ++--
 2 files changed, 41 insertions(+), 48 deletions(-)

diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index 4d09c86..a7b4dcb 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -100,63 +100,46 @@ void vpmu_lvtpc_update(uint32_t val)
 apic_write(APIC_LVTPC, vpmu->hw_lapic_lvtpc);
 }
 
-int vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content, uint64_t supported)
+int vpmu_do_msr(unsigned int msr, uint64_t *msr_content,
+uint64_t supported, bool_t is_write)
 {
 struct vcpu *curr = current;
 struct vpmu_struct *vpmu;
+const struct arch_vpmu_ops *ops;
+int ret = 0;
 
-if ( vpmu_mode == XENPMU_MODE_OFF )
-return 0;
+if ( likely(vpmu_mode == XENPMU_MODE_OFF) )
+goto nop;
 
 vpmu = vcpu_vpmu(curr);
-if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->do_wrmsr )
-{
-int ret = vpmu->arch_vpmu_ops->do_wrmsr(msr, msr_content, supported);
-
-/*
- * We may have received a PMU interrupt during WRMSR handling
- * and since do_wrmsr may load VPMU context we should save
- * (and unload) it again.
- */
-if ( !is_hvm_vcpu(curr) && vpmu->xenpmu_data &&
- vpmu_is_set(vpmu, VPMU_CACHED) )
-{
-vpmu_set(vpmu, VPMU_CONTEXT_SAVE);
-vpmu->arch_vpmu_ops->arch_vpmu_save(curr, 0);
-vpmu_reset(vpmu, VPMU_CONTEXT_SAVE | VPMU_CONTEXT_LOADED);
-}
-return ret;
-}
-
-return 0;
-}
-
-int vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content)
-{
-struct vcpu *curr = current;
-struct vpmu_struct *vpmu;
+ops = vpmu->arch_vpmu_ops;
+if ( !ops )
+goto nop;
+
+if ( is_write && ops->do_wrmsr )
+ret = ops->do_wrmsr(msr, *msr_content, supported);
+else if ( !is_write && ops->do_rdmsr )
+ret = ops->do_rdmsr(msr, msr_content);
+else
+goto nop;
 
-if ( vpmu_mode == XENPMU_MODE_OFF )
+/*
+ * We may have received a PMU interrupt while handling MSR access
+ * and since do_wr/rdmsr may load VPMU context we should save
+ * (and unload) it again.
+ */
+if ( !is_hvm_vcpu(curr) && vpmu->xenpmu_data &&
+vpmu_is_set(vpmu, VPMU_CACHED) )
 {
-*msr_content = 0;
-return 0;
+vpmu_set(vpmu, VPMU_CONTEXT_SAVE);
+ops->arch_vpmu_save(curr, 0);
+vpmu_reset(vpmu, VPMU_CONTEXT_SAVE | VPMU_CONTEXT_LOADED);
 }
 
-vpmu = vcpu_vpmu(curr);
-if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->do_rdmsr )
-{
-int ret = vpmu->arch_vpmu_ops->do_rdmsr(msr, msr_content);
+return ret;
 
-if ( !is_hvm_vcpu(curr) && vpmu->xenpmu_data &&
- vpmu_is_set(vpmu, VPMU_CACHED) )
-{
-vpmu_set(vpmu, VPMU_CONTEXT_SAVE);
-vpmu->arch_vpmu_ops->arch_vpmu_save(curr, 0);
-vpmu_reset(vpmu, VPMU_CONTEXT_SAVE | VPMU_CONTEXT_LOADED);
-}
-return ret;
-}
-else
+ nop:
+if ( !is_write )
 *msr_content = 0;
 
 return 0;
diff --git a/xen/include/asm-x86/hvm/vpmu.h b/xen/include/asm-x86/hvm/vpmu.h
index f486d2f..212e496 100644
--- a/xen/include/asm-x86/hvm/vpmu.h
+++ b/xen/include/asm-x86/hvm/vpmu.h
@@ -101,8 +101,8 @@ static inline bool_t vpmu_are_all_set(const struct 
vpmu_struct *vpmu,
 }
 
 void vpmu_lvtpc_update(uint32_t val);
-int vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content, uint64_t supported);
-int vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content);
+int vpmu_do_msr(unsigned int msr, uint64_t *msr_content,
+uint64_t supported, bool_t is_write);
 void vpmu_do_interrupt(struct cpu_user_regs *regs);
 void vpmu_do_cpuid(unsigned int input, unsigned int *eax, unsigned int *ebx,
unsigned int *ecx, unsigned int *edx);
@@ -112,6 +112,16 @@ void vpmu_save(struct vcpu *v);
 int vpmu_load(struct vcpu *v, bool_t from_guest);
 void vpmu_dump(struct vcpu *v);
 
+static inline int vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
+uint64_t supported)
+{
+return vpmu_do_msr(msr, &msr_content, supported, 1);
+}
+static inline int vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content)
+{
+return vpmu_do_msr(msr, msr_content, 0, 0);
+}
+
 extern int acquire_pmu_ownership(int pmu_ownership);
 extern void release_pmu_ownership(int pmu_ownership);
 
-- 
1.8.1.4


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

[Xen-devel] [PATCH v22 06/14] x86/VPMU: Initialize PMU for PV(H) guests

[Boris Ostrovsky]

Code for initializing/tearing down PMU for PV guests

Signed-off-by: Boris Ostrovsky 
Acked-by: Daniel De Graaf 
Acked-by: Jan Beulich 
---
 tools/flask/policy/policy/modules/xen/xen.te |   4 +
 xen/arch/x86/domain.c|   2 +
 xen/arch/x86/hvm/hvm.c   |   1 +
 xen/arch/x86/hvm/svm/svm.c   |   4 +-
 xen/arch/x86/hvm/svm/vpmu.c  |  16 +++-
 xen/arch/x86/hvm/vmx/vmx.c   |   4 +-
 xen/arch/x86/hvm/vmx/vpmu_core2.c|  30 --
 xen/arch/x86/hvm/vpmu.c  | 131 ---
 xen/common/event_channel.c   |   1 +
 xen/include/asm-x86/hvm/vpmu.h   |   2 +
 xen/include/public/pmu.h |   2 +
 xen/include/public/xen.h |   1 +
 xen/include/xsm/dummy.h  |   3 +
 xen/xsm/flask/hooks.c|   4 +
 xen/xsm/flask/policy/access_vectors  |   2 +
 15 files changed, 181 insertions(+), 26 deletions(-)

diff --git a/tools/flask/policy/policy/modules/xen/xen.te 
b/tools/flask/policy/policy/modules/xen/xen.te
index 2f4e419..5bc1958 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -120,6 +120,10 @@ domain_comms(dom0_t, dom0_t)
 # Allow all domains to use (unprivileged parts of) the tmem hypercall
 allow domain_type xen_t:xen tmem_op;
 
+# Allow all domains to use PMU (but not to change its settings --- that's what
+# pmu_ctrl is for)
+allow domain_type xen_t:xen2 pmu_use;
+
 ###
 #
 # Domain creation
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index e0f859f..6ff70ea 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -438,6 +438,8 @@ int vcpu_initialise(struct vcpu *v)
 vmce_init_vcpu(v);
 }
 
+spin_lock_init(&v->arch.vpmu.vpmu_lock);
+
 if ( has_hvm_container_domain(d) )
 {
 rc = hvm_vcpu_initialise(v);
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 89423fa..0e5669d 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4911,6 +4911,7 @@ static hvm_hypercall_t *const 
pvh_hypercall64_table[NR_hypercalls] = {
 HYPERCALL(hvm_op),
 HYPERCALL(sysctl),
 HYPERCALL(domctl),
+HYPERCALL(xenpmu_op),
 [ __HYPERVISOR_arch_1 ] = (hvm_hypercall_t *)paging_domctl_continuation
 };
 
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 6734fb6..49d2ddf 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1165,7 +1165,9 @@ static int svm_vcpu_initialise(struct vcpu *v)
 return rc;
 }
 
-vpmu_initialise(v);
+/* PVH's VPMU is initialized via hypercall */
+if ( is_hvm_vcpu(v) )
+vpmu_initialise(v);
 
 svm_guest_osvw_init(v);
 
diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index b60ca40..a8572a6 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -364,13 +364,11 @@ static void amd_vpmu_destroy(struct vcpu *v)
 amd_vpmu_unset_msr_bitmap(v);
 
 xfree(vpmu->context);
-vpmu_reset(vpmu, VPMU_CONTEXT_ALLOCATED);
 
 if ( vpmu_is_set(vpmu, VPMU_RUNNING) )
-{
-vpmu_reset(vpmu, VPMU_RUNNING);
 release_pmu_ownship(PMU_OWNER_HVM);
-}
+
+vpmu_clear(vpmu);
 }
 
 /* VPMU part of the 'q' keyhandler */
@@ -482,6 +480,16 @@ int __init amd_vpmu_init(void)
 return -EINVAL;
 }
 
+if ( sizeof(struct xen_pmu_data) +
+ 2 * sizeof(uint64_t) * num_counters > PAGE_SIZE )
+{
+printk(XENLOG_WARNING
+   "VPMU: Register bank does not fit into VPMU shared page\n");
+counters = ctrls = NULL;
+num_counters = 0;
+return -ENOSPC;
+}
+
 return 0;
 }
 
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 74f563f..9ebff99 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -139,7 +139,9 @@ static int vmx_vcpu_initialise(struct vcpu *v)
 }
 }
 
-vpmu_initialise(v);
+/* PVH's VPMU is initialized via hypercall */
+if ( is_hvm_vcpu(v) )
+vpmu_initialise(v);
 
 vmx_install_vlapic_mapping(v);
 
diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c 
b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index 1d301a2..d850903 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -365,13 +365,16 @@ static int core2_vpmu_alloc_resource(struct vcpu *v)
 if ( !acquire_pmu_ownership(PMU_OWNER_HVM) )
 return 0;
 
-wrmsrl(MSR_CORE_PERF_GLOBAL_CTRL, 0);
-if ( vmx_add_host_load_msr(MSR_CORE_PERF_GLOBAL_CTRL) )
-goto out_err;
+if ( has_hvm_container_vcpu(v) )
+{
+wrmsrl(MSR_CORE_PERF_GLOBAL_CTRL, 0);
+if ( vmx_add_host_load_msr(MSR_CORE_PERF_GLOBAL_CTRL) )
+goto out_err;
 
-if ( vmx_add_guest_msr(MSR_

[Xen-devel] [PATCH v22 10/14] x86/VPMU: Use pre-computed masks when checking validity of MSRs

[Boris Ostrovsky]

No need to compute those masks on every MSR access.

Signed-off-by: Boris Ostrovsky 
---
Changes in v22:
* Added ARCH_CNTR_ENABLED macro

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

diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c 
b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index e5478a1..e8d9bb4 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -80,9 +80,16 @@ static bool_t __read_mostly full_width_write;
 #define FIXED_CTR_CTRL_BITS 4
 #define FIXED_CTR_CTRL_MASK ((1 << FIXED_CTR_CTRL_BITS) - 1)
 
+#define ARCH_CNTR_ENABLED   (1ULL << 22)
+
 /* Number of general-purpose and fixed performance counters */
 static unsigned int __read_mostly arch_pmc_cnt, fixed_pmc_cnt;
 
+/* Masks used for testing whether and MSR is valid */
+#define ARCH_CTRL_MASK  (~((1ull << 32) - 1) | (1ull << 21))
+static uint64_t __read_mostly fixed_ctrl_mask, fixed_counters_mask;
+static uint64_t __read_mostly global_ovf_ctrl_mask;
+
 /*
  * QUIRK to workaround an issue on various family 6 cpus.
  * The issue leads to endless PMC interrupt loops on the processor.
@@ -479,9 +486,7 @@ static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t 
msr_content,
 
 ASSERT(!supported);
 
-if ( type == MSR_TYPE_COUNTER &&
- (msr_content &
-  ~((1ull << core2_get_bitwidth_fix_count()) - 1)) )
+if ( (type == MSR_TYPE_COUNTER) && (msr_content & fixed_counters_mask) )
 /* Writing unsupported bits to a fixed counter */
 return 1;
 
@@ -490,9 +495,7 @@ static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t 
msr_content,
 switch ( msr )
 {
 case MSR_CORE_PERF_GLOBAL_OVF_CTRL:
-if ( msr_content & ~(0xC000 |
- (((1ULL << fixed_pmc_cnt) - 1) << 32) |
- ((1ULL << arch_pmc_cnt) - 1)) )
+if ( msr_content & global_ovf_ctrl_mask )
 return 1;
 core2_vpmu_cxt->global_status &= ~msr_content;
 wrmsrl(MSR_CORE_PERF_GLOBAL_OVF_CTRL, msr_content);
@@ -526,8 +529,7 @@ static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t 
msr_content,
 core2_vpmu_cxt->global_ctrl = msr_content;
 break;
 case MSR_CORE_PERF_FIXED_CTR_CTRL:
-if ( msr_content &
- ( ~((1ull << (fixed_pmc_cnt * FIXED_CTR_CTRL_BITS)) - 1)) )
+if ( msr_content & fixed_ctrl_mask )
 return 1;
 
 if ( has_hvm_container_vcpu(v) )
@@ -556,7 +558,7 @@ static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t 
msr_content,
 struct xen_pmu_cntr_pair *xen_pmu_cntr_pair =
 vpmu_reg_pointer(core2_vpmu_cxt, arch_counters);
 
-if ( msr_content & (~((1ull << 32) - 1)) )
+if ( msr_content & ARCH_CTRL_MASK )
 return 1;
 
 if ( has_hvm_container_vcpu(v) )
@@ -565,7 +567,7 @@ static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t 
msr_content,
 else
 rdmsrl(MSR_CORE_PERF_GLOBAL_CTRL, core2_vpmu_cxt->global_ctrl);
 
-if ( msr_content & (1ULL << 22) )
+if ( msr_content & ARCH_CNTR_ENABLED )
 *enabled_cntrs |= 1ULL << tmp;
 else
 *enabled_cntrs &= ~(1ULL << tmp);
@@ -915,6 +917,12 @@ int __init core2_vpmu_init(void)
 rdmsrl(MSR_IA32_PERF_CAPABILITIES, caps);
 full_width_write = (caps >> 13) & 1;
 
+fixed_ctrl_mask = ~((1ull << (fixed_pmc_cnt * FIXED_CTR_CTRL_BITS)) - 1);
+fixed_counters_mask = ~((1ull << core2_get_bitwidth_fix_count()) - 1);
+global_ovf_ctrl_mask = ~(0xC000 |
+ (((1ULL << fixed_pmc_cnt) - 1) << 32) |
+ ((1ULL << arch_pmc_cnt) - 1));
+
 check_pmc_quirk();
 
 if ( sizeof(struct xen_pmu_data) + sizeof(uint64_t) * fixed_pmc_cnt +
-- 
1.8.1.4


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

[Xen-devel] [PATCH v22 04/14] x86/VPMU: Interface for setting PMU mode and flags

[Boris Ostrovsky]

Add runtime interface for setting PMU mode and flags. Three main modes are
provided:
* XENPMU_MODE_OFF:  PMU is not virtualized
* XENPMU_MODE_SELF: Guests can access PMU MSRs and receive PMU interrupts.
* XENPMU_MODE_HV: Same as XENPMU_MODE_SELF for non-proviledged guests, dom0
  can profile itself and the hypervisor.

Note that PMU modes are different from what can be provided at Xen's boot line
with 'vpmu' argument. An 'off' (or '0') value is equivalent to XENPMU_MODE_OFF.
Any other value, on the other hand, will cause VPMU mode to be set to
XENPMU_MODE_SELF during boot.

For feature flags only Intel's BTS is currently supported.

Mode and flags are set via HYPERVISOR_xenpmu_op hypercall.

Signed-off-by: Boris Ostrovsky 
Acked-by: Daniel De Graaf 
Acked-by: Jan Beulich 
Reviewed-by: Dietmar Hahn 
---
 tools/flask/policy/policy/modules/xen/xen.te |   3 +
 xen/arch/x86/domain.c|   4 +-
 xen/arch/x86/hvm/svm/vpmu.c  |   4 +-
 xen/arch/x86/hvm/vmx/vpmu_core2.c|  10 +-
 xen/arch/x86/hvm/vpmu.c  | 159 +--
 xen/arch/x86/x86_64/compat/entry.S   |   4 +
 xen/arch/x86/x86_64/entry.S  |   4 +
 xen/include/asm-x86/hvm/vpmu.h   |  27 +++--
 xen/include/public/pmu.h |  46 
 xen/include/public/xen.h |   1 +
 xen/include/xen/hypercall.h  |   4 +
 xen/include/xlat.lst |   1 +
 xen/include/xsm/dummy.h  |  15 +++
 xen/include/xsm/xsm.h|   6 +
 xen/xsm/dummy.c  |   1 +
 xen/xsm/flask/hooks.c|  18 +++
 xen/xsm/flask/policy/access_vectors  |   2 +
 17 files changed, 284 insertions(+), 25 deletions(-)

diff --git a/tools/flask/policy/policy/modules/xen/xen.te 
b/tools/flask/policy/policy/modules/xen/xen.te
index ce70639..2f4e419 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -68,6 +68,9 @@ allow dom0_t xen_t:xen2 {
 resource_op
 psr_cmt_op
 };
+allow dom0_t xen_t:xen2 {
+pmu_ctrl
+};
 allow dom0_t xen_t:mmu memorymap;
 
 # Allow dom0 to use these domctls on itself. For domctls acting on other
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 6e9464c..e0f859f 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1540,7 +1540,7 @@ void context_switch(struct vcpu *prev, struct vcpu *next)
 if ( is_hvm_vcpu(prev) )
 {
 if (prev != next)
-vpmu_save(prev);
+vpmu_switch_from(prev);
 
 if ( !list_empty(&prev->arch.hvm_vcpu.tm_list) )
 pt_save_timer(prev);
@@ -1585,7 +1585,7 @@ void context_switch(struct vcpu *prev, struct vcpu *next)
 
 if (is_hvm_vcpu(next) && (prev != next) )
 /* Must be done with interrupts enabled */
-vpmu_load(next);
+vpmu_switch_to(next);
 
 context_saved(prev);
 
diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index a8b79df..481ea7b 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -472,14 +472,14 @@ struct arch_vpmu_ops amd_vpmu_ops = {
 .arch_vpmu_dump = amd_vpmu_dump
 };
 
-int svm_vpmu_initialise(struct vcpu *v, unsigned int vpmu_flags)
+int svm_vpmu_initialise(struct vcpu *v)
 {
 struct vpmu_struct *vpmu = vcpu_vpmu(v);
 uint8_t family = current_cpu_data.x86;
 int ret = 0;
 
 /* vpmu enabled? */
-if ( !vpmu_flags )
+if ( vpmu_mode == XENPMU_MODE_OFF )
 return 0;
 
 switch ( family )
diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c 
b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index bbc68e2..9dca51b 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -708,13 +708,13 @@ static int core2_vpmu_do_interrupt(struct cpu_user_regs 
*regs)
 return 1;
 }
 
-static int core2_vpmu_initialise(struct vcpu *v, unsigned int vpmu_flags)
+static int core2_vpmu_initialise(struct vcpu *v)
 {
 struct vpmu_struct *vpmu = vcpu_vpmu(v);
 u64 msr_content;
 static bool_t ds_warned;
 
-if ( !(vpmu_flags & VPMU_BOOT_BTS) )
+if ( !(vpmu_features & XENPMU_FEATURE_INTEL_BTS) )
 goto func_out;
 /* Check the 'Debug Store' feature in the CPUID.EAX[1]:EDX[21] */
 while ( boot_cpu_has(X86_FEATURE_DS) )
@@ -826,7 +826,7 @@ struct arch_vpmu_ops core2_no_vpmu_ops = {
 .do_cpuid = core2_no_vpmu_do_cpuid,
 };
 
-int vmx_vpmu_initialise(struct vcpu *v, unsigned int vpmu_flags)
+int vmx_vpmu_initialise(struct vcpu *v)
 {
 struct vpmu_struct *vpmu = vcpu_vpmu(v);
 uint8_t family = current_cpu_data.x86;
@@ -834,7 +834,7 @@ int vmx_vpmu_initialise(struct vcpu *v, unsigned int 
vpmu_flags)
 int ret = 0;
 
 vpmu->arch_vpmu_ops = &core2_no_vpmu_ops;
-if ( !vpmu_flags )
+if ( vpmu_mode == XENPMU_MODE_OFF )
 return 0;
 
 if ( family == 6 )
@@ -884,7 +

[Xen-devel] [PATCH v22 08/14] x86/VPMU: When handling MSR accesses, leave fault injection to callers

[Boris Ostrovsky]

With this patch return value of 1 of vpmu_do_msr() will now indicate whether an
error was encountered during MSR processing (instead of stating that the access
was to a VPMU register).

As part of this patch we also check for validity of certain MSR accesses right
when we determine which register is being written, as opposed to postponing this
until later.

Signed-off-by: Boris Ostrovsky 
Acked-by: Kevin Tian 
Reviewed-by: Dietmar Hahn 
Tested-by: Dietmar Hahn 
---
 xen/arch/x86/hvm/svm/svm.c|  6 ++-
 xen/arch/x86/hvm/svm/vpmu.c   |  6 +--
 xen/arch/x86/hvm/vmx/vmx.c| 24 +---
 xen/arch/x86/hvm/vmx/vpmu_core2.c | 82 ++-
 4 files changed, 55 insertions(+), 63 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 49d2ddf..08a44f2 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1708,7 +1708,8 @@ static int svm_msr_read_intercept(unsigned int msr, 
uint64_t *msr_content)
 case MSR_AMD_FAM15H_EVNTSEL3:
 case MSR_AMD_FAM15H_EVNTSEL4:
 case MSR_AMD_FAM15H_EVNTSEL5:
-vpmu_do_rdmsr(msr, msr_content);
+if ( vpmu_do_rdmsr(msr, msr_content) )
+goto gpf;
 break;
 
 case MSR_AMD64_DR0_ADDRESS_MASK:
@@ -1859,7 +1860,8 @@ static int svm_msr_write_intercept(unsigned int msr, 
uint64_t msr_content)
 case MSR_AMD_FAM15H_EVNTSEL3:
 case MSR_AMD_FAM15H_EVNTSEL4:
 case MSR_AMD_FAM15H_EVNTSEL5:
-vpmu_do_wrmsr(msr, msr_content, 0);
+if ( vpmu_do_wrmsr(msr, msr_content, 0) )
+goto gpf;
 break;
 
 case MSR_IA32_MCx_MISC(4): /* Threshold register */
diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index a8572a6..74d03a5 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -305,7 +305,7 @@ static int amd_vpmu_do_wrmsr(unsigned int msr, uint64_t 
msr_content,
 is_pmu_enabled(msr_content) && !vpmu_is_set(vpmu, VPMU_RUNNING) )
 {
 if ( !acquire_pmu_ownership(PMU_OWNER_HVM) )
-return 1;
+return 0;
 vpmu_set(vpmu, VPMU_RUNNING);
 
 if ( has_hvm_container_vcpu(v) && is_msr_bitmap_on(vpmu) )
@@ -335,7 +335,7 @@ static int amd_vpmu_do_wrmsr(unsigned int msr, uint64_t 
msr_content,
 
 /* Write to hw counters */
 wrmsrl(msr, msr_content);
-return 1;
+return 0;
 }
 
 static int amd_vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content)
@@ -353,7 +353,7 @@ static int amd_vpmu_do_rdmsr(unsigned int msr, uint64_t 
*msr_content)
 
 rdmsrl(msr, *msr_content);
 
-return 1;
+return 0;
 }
 
 static void amd_vpmu_destroy(struct vcpu *v)
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 9ebff99..80bb158 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2164,12 +2164,17 @@ static int vmx_msr_read_intercept(unsigned int msr, 
uint64_t *msr_content)
 *msr_content |= MSR_IA32_MISC_ENABLE_BTS_UNAVAIL |
MSR_IA32_MISC_ENABLE_PEBS_UNAVAIL;
 /* Perhaps vpmu will change some bits. */
+/* FALLTHROUGH */
+case MSR_P6_PERFCTR(0)...MSR_P6_PERFCTR(7):
+case MSR_P6_EVNTSEL(0)...MSR_P6_EVNTSEL(3):
+case MSR_CORE_PERF_FIXED_CTR0...MSR_CORE_PERF_FIXED_CTR2:
+case MSR_CORE_PERF_FIXED_CTR_CTRL...MSR_CORE_PERF_GLOBAL_OVF_CTRL:
+case MSR_IA32_PEBS_ENABLE:
+case MSR_IA32_DS_AREA:
 if ( vpmu_do_rdmsr(msr, msr_content) )
-goto done;
+goto gp_fault;
 break;
 default:
-if ( vpmu_do_rdmsr(msr, msr_content) )
-break;
 if ( passive_domain_do_rdmsr(msr, msr_content) )
 goto done;
 switch ( long_mode_do_msr_read(msr, msr_content) )
@@ -2345,7 +2350,7 @@ static int vmx_msr_write_intercept(unsigned int msr, 
uint64_t msr_content)
 if ( msr_content & ~supported )
 {
 /* Perhaps some other bits are supported in vpmu. */
-if ( !vpmu_do_wrmsr(msr, msr_content, supported) )
+if ( vpmu_do_wrmsr(msr, msr_content, supported) )
 break;
 }
 if ( msr_content & IA32_DEBUGCTLMSR_LBR )
@@ -2373,9 +2378,16 @@ static int vmx_msr_write_intercept(unsigned int msr, 
uint64_t msr_content)
 if ( !nvmx_msr_write_intercept(msr, msr_content) )
 goto gp_fault;
 break;
+case MSR_P6_PERFCTR(0)...MSR_P6_PERFCTR(7):
+case MSR_P6_EVNTSEL(0)...MSR_P6_EVNTSEL(7):
+case MSR_CORE_PERF_FIXED_CTR0...MSR_CORE_PERF_FIXED_CTR2:
+case MSR_CORE_PERF_FIXED_CTR_CTRL...MSR_CORE_PERF_GLOBAL_OVF_CTRL:
+case MSR_IA32_PEBS_ENABLE:
+case MSR_IA32_DS_AREA:
+ if ( vpmu_do_wrmsr(msr, msr_content, 0) )
+goto gp_fault;
+break;
 default:
-if ( vpmu_do_wrmsr(msr, msr_content, 0) )
-return X86EMUL_OKAY;
 if ( passive_domain_do_wrmsr(msr, msr_content) )
 return X86EMUL_O

[Xen-devel] [PATCH v22 11/14] x86/VPMU: Handle PMU interrupts for PV(H) guests

[Boris Ostrovsky]

Add support for handling PMU interrupts for PV(H) guests.

VPMU for the interrupted VCPU is unloaded until the guest issues XENPMU_flush
hypercall. This allows the guest to access PMU MSR values that are stored in
VPMU context which is shared between hypervisor and domain, thus avoiding
traps to hypervisor.

Since the interrupt handler may now force VPMU context save (i.e. set
VPMU_CONTEXT_SAVE flag) we need to make changes to amd_vpmu_save() which
until now expected this flag to be set only when the counters were stopped.

Signed-off-by: Boris Ostrovsky 
Acked-by: Daniel De Graaf 
---
Changes in v22:
* Redefined ctxt_sz to be unsigned int (both SVM and VMX)
* Fixed inconsistent naming for vpmu load routines(to_guest/to_user/verify)
* Made priv_context recalculation in core2_vpmu_verify() more readable
* Made core2_vpmu_verify() return error code (-EINVAL only for now) instead of
  1 or 0
* Use hypervisor-private VPMU_CACHED flag instead of PMU_CACHED flag in shared
  area (but keep the latter for the guest use)
* Test 'vpmu->arch_vpmu_ops == NULL' in the beginning of vpmu_do_interrupt() to
  avoid multiple test sites


 xen/arch/x86/hvm/svm/vpmu.c   |  63 ++---
 xen/arch/x86/hvm/vmx/vpmu_core2.c |  91 -
 xen/arch/x86/hvm/vpmu.c   | 265 +-
 xen/include/asm-x86/hvm/vpmu.h|  10 +-
 xen/include/public/arch-x86/pmu.h |   3 +
 xen/include/public/pmu.h  |   2 +
 xen/include/xsm/dummy.h   |   4 +-
 xen/xsm/flask/hooks.c |   2 +
 8 files changed, 382 insertions(+), 58 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index 74d03a5..08acbda 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -45,6 +45,7 @@ static unsigned int __read_mostly num_counters;
 static const u32 __read_mostly *counters;
 static const u32 __read_mostly *ctrls;
 static bool_t __read_mostly k7_counters_mirrored;
+static unsigned int __read_mostly ctxt_sz;
 
 #define F10H_NUM_COUNTERS   4
 #define F15H_NUM_COUNTERS   6
@@ -188,27 +189,52 @@ static inline void context_load(struct vcpu *v)
 }
 }
 
-static void amd_vpmu_load(struct vcpu *v)
+static int amd_vpmu_load(struct vcpu *v, bool_t from_guest)
 {
 struct vpmu_struct *vpmu = vcpu_vpmu(v);
-struct xen_pmu_amd_ctxt *ctxt = vpmu->context;
-uint64_t *ctrl_regs = vpmu_reg_pointer(ctxt, ctrls);
+struct xen_pmu_amd_ctxt *ctxt;
+uint64_t *ctrl_regs;
+unsigned int i;
 
 vpmu_reset(vpmu, VPMU_FROZEN);
 
-if ( vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED) )
+if ( !from_guest && vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED) )
 {
-unsigned int i;
+ctxt = vpmu->context;
+ctrl_regs = vpmu_reg_pointer(ctxt, ctrls);
 
 for ( i = 0; i < num_counters; i++ )
 wrmsrl(ctrls[i], ctrl_regs[i]);
 
-return;
+return 0;
+}
+
+if ( from_guest )
+{
+ASSERT(!is_hvm_vcpu(v));
+
+ctxt = &vpmu->xenpmu_data->pmu.c.amd;
+ctrl_regs = vpmu_reg_pointer(ctxt, ctrls);
+for ( i = 0; i < num_counters; i++ )
+{
+if ( is_pmu_enabled(ctrl_regs[i]) )
+{
+vpmu_set(vpmu, VPMU_RUNNING);
+break;
+}
+}
+
+if ( i == num_counters )
+vpmu_reset(vpmu, VPMU_RUNNING);
+
+memcpy(vpmu->context, &vpmu->xenpmu_data->pmu.c.amd, ctxt_sz);
 }
 
 vpmu_set(vpmu, VPMU_CONTEXT_LOADED);
 
 context_load(v);
+
+return 0;
 }
 
 static inline void context_save(struct vcpu *v)
@@ -223,22 +249,17 @@ static inline void context_save(struct vcpu *v)
 rdmsrl(counters[i], counter_regs[i]);
 }
 
-static int amd_vpmu_save(struct vcpu *v)
+static int amd_vpmu_save(struct vcpu *v,  bool_t to_guest)
 {
 struct vpmu_struct *vpmu = vcpu_vpmu(v);
 unsigned int i;
 
-/*
- * Stop the counters. If we came here via vpmu_save_force (i.e.
- * when VPMU_CONTEXT_SAVE is set) counters are already stopped.
- */
+for ( i = 0; i < num_counters; i++ )
+wrmsrl(ctrls[i], 0);
+
 if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_SAVE) )
 {
 vpmu_set(vpmu, VPMU_FROZEN);
-
-for ( i = 0; i < num_counters; i++ )
-wrmsrl(ctrls[i], 0);
-
 return 0;
 }
 
@@ -251,6 +272,12 @@ static int amd_vpmu_save(struct vcpu *v)
  has_hvm_container_vcpu(v) && is_msr_bitmap_on(vpmu) )
 amd_vpmu_unset_msr_bitmap(v);
 
+if ( to_guest )
+{
+ASSERT(!is_hvm_vcpu(v));
+memcpy(&vpmu->xenpmu_data->pmu.c.amd, vpmu->context, ctxt_sz);
+}
+
 return 1;
 }
 
@@ -433,8 +460,7 @@ int svm_vpmu_initialise(struct vcpu *v)
 if ( !counters )
 return -EINVAL;
 
-ctxt = xzalloc_bytes(sizeof(*ctxt) +
- 2 * sizeof(uint64_t) * num_counters);
+ctxt = xzalloc_bytes(ctxt_sz);
 if ( !ctxt )
 {
 printk(XENLOG_G_WARNING "Insufficient memory for PMU, "

[Xen-devel] [PATCH v22 14/14] x86/VPMU: Move VPMU files up from hvm/ directory

[Boris Ostrovsky]

Since PMU is now not HVM specific we can move VPMU-related files up from
arch/x86/hvm/ directory.

Specifically:
arch/x86/hvm/vpmu.c -> arch/x86/cpu/vpmu.c
arch/x86/hvm/svm/vpmu.c -> arch/x86/cpu/vpmu_amd.c
arch/x86/hvm/vmx/vpmu_core2.c -> arch/x86/cpu/vpmu_intel.c
include/asm-x86/hvm/vpmu.h -> include/asm-x86/vpmu.h

Signed-off-by: Boris Ostrovsky 
Acked-by: Jan Beulich 
Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Dietmar Hahn 
Tested-by: Dietmar Hahn 
---
 xen/arch/x86/cpu/Makefile   | 1 +
 xen/arch/x86/{hvm => cpu}/vpmu.c| 2 +-
 xen/arch/x86/{hvm/svm/vpmu.c => cpu/vpmu_amd.c} | 2 +-
 xen/arch/x86/{hvm/vmx/vpmu_core2.c => cpu/vpmu_intel.c} | 2 +-
 xen/arch/x86/hvm/Makefile   | 1 -
 xen/arch/x86/hvm/svm/Makefile   | 1 -
 xen/arch/x86/hvm/vlapic.c   | 2 +-
 xen/arch/x86/hvm/vmx/Makefile   | 1 -
 xen/arch/x86/oprofile/op_model_ppro.c   | 2 +-
 xen/arch/x86/traps.c| 2 +-
 xen/include/asm-x86/hvm/vmx/vmcs.h  | 2 +-
 xen/include/asm-x86/{hvm => }/vpmu.h| 0
 12 files changed, 8 insertions(+), 10 deletions(-)
 rename xen/arch/x86/{hvm => cpu}/vpmu.c (99%)
 rename xen/arch/x86/{hvm/svm/vpmu.c => cpu/vpmu_amd.c} (99%)
 rename xen/arch/x86/{hvm/vmx/vpmu_core2.c => cpu/vpmu_intel.c} (99%)
 rename xen/include/asm-x86/{hvm => }/vpmu.h (100%)

diff --git a/xen/arch/x86/cpu/Makefile b/xen/arch/x86/cpu/Makefile
index d73d93a..74f23ae 100644
--- a/xen/arch/x86/cpu/Makefile
+++ b/xen/arch/x86/cpu/Makefile
@@ -7,3 +7,4 @@ obj-y += common.o
 obj-y += intel.o
 obj-y += intel_cacheinfo.o
 obj-y += mwait-idle.o
+obj-y += vpmu.o vpmu_amd.o vpmu_intel.o
diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/cpu/vpmu.c
similarity index 99%
rename from xen/arch/x86/hvm/vpmu.c
rename to xen/arch/x86/cpu/vpmu.c
index 2eb369c..23b7c4f 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/cpu/vpmu.c
@@ -28,10 +28,10 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/cpu/vpmu_amd.c
similarity index 99%
rename from xen/arch/x86/hvm/svm/vpmu.c
rename to xen/arch/x86/cpu/vpmu_amd.c
index 08acbda..16df4dd 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/cpu/vpmu_amd.c
@@ -28,8 +28,8 @@
 #include 
 #include 
 #include 
+#include 
 #include 
-#include 
 #include 
 
 #define MSR_F10H_EVNTSEL_GO_SHIFT   40
diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c b/xen/arch/x86/cpu/vpmu_intel.c
similarity index 99%
rename from xen/arch/x86/hvm/vmx/vpmu_core2.c
rename to xen/arch/x86/cpu/vpmu_intel.c
index 52a945f..9210a48 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/cpu/vpmu_intel.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -37,7 +38,6 @@
 #include 
 #include 
 #include 
-#include 
 
 /*
  * See Intel SDM Vol 2a Instruction Set Reference chapter 3 for CPUID
diff --git a/xen/arch/x86/hvm/Makefile b/xen/arch/x86/hvm/Makefile
index 69af47f..794e793 100644
--- a/xen/arch/x86/hvm/Makefile
+++ b/xen/arch/x86/hvm/Makefile
@@ -23,4 +23,3 @@ obj-y += vlapic.o
 obj-y += vmsi.o
 obj-y += vpic.o
 obj-y += vpt.o
-obj-y += vpmu.o
diff --git a/xen/arch/x86/hvm/svm/Makefile b/xen/arch/x86/hvm/svm/Makefile
index a10a55e..760d295 100644
--- a/xen/arch/x86/hvm/svm/Makefile
+++ b/xen/arch/x86/hvm/svm/Makefile
@@ -6,4 +6,3 @@ obj-y += nestedsvm.o
 obj-y += svm.o
 obj-y += svmdebug.o
 obj-y += vmcb.o
-obj-y += vpmu.o
diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
index 92b0fa8..e03d670 100644
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -33,12 +33,12 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
diff --git a/xen/arch/x86/hvm/vmx/Makefile b/xen/arch/x86/hvm/vmx/Makefile
index 373b3d9..04a29ce 100644
--- a/xen/arch/x86/hvm/vmx/Makefile
+++ b/xen/arch/x86/hvm/vmx/Makefile
@@ -3,5 +3,4 @@ obj-y += intr.o
 obj-y += realmode.o
 obj-y += vmcs.o
 obj-y += vmx.o
-obj-y += vpmu_core2.o
 obj-y += vvmx.o
diff --git a/xen/arch/x86/oprofile/op_model_ppro.c 
b/xen/arch/x86/oprofile/op_model_ppro.c
index ca429a1..89649d0 100644
--- a/xen/arch/x86/oprofile/op_model_ppro.c
+++ b/xen/arch/x86/oprofile/op_model_ppro.c
@@ -19,7 +19,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include "op_x86_model.h"
 #include "op_counter.h"
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index b4215f7..fbd6a40 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -72,7 +72,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 
diff --git a/xen/include/asm-x86/hvm/vmx/vmcs.h 
b/xen/include/asm-x86/hvm/vmx/vmcs.h
index 1104bda..3132644

[Xen-devel] [PATCH v22 00/14] x86/PMU: Xen PMU PV(H) support

[Boris Ostrovsky]

Changes in v22:
* Clarified access permissions on shared fileds (patch 2)
* Added ARCH_CNTR_ENABLED macro (patch 10)
* Use hypervisor-private VPMU_CACHED instead of shared PMU_CACHED
  (patch 11)
* A few cleanups (patch 11)

Changes in v21:

* Keep running VPMU's context private to hypervisor and expose
  it only during interrupt handling. Verify content of guest-updated
  context before loading into HW. Affected patches are 6 and (mostly) 11.
* Pre-compute some of the masks used for verification (new patch 10)
* Document shared data in public header files
* A couple of ARM-related fixes (patches 1 and 2)

Changes in v20:

* Made xen_pmu_data's domain_id a domid_t type, resulting in
  layout/padding changes (patches 2 and 10)
* Added compat checks for xen_pmu_data (patch 2)
* Clarified how vpmu_count is used in a comment (patch 6)
* Moved page management from under vpmu_lock (patch 6)
* Other (mostly style-related) changes in per-patch notes


Changes in v19:

* Do not allow changing mode to/from OFF/ALL while guests are
  running. This significantly simplifies code due
  to large number of corner cases that I had to deal with. Most of the
  changes are in patch#5. This also makes patch 4 from last version
  unnecessary
* Defer NMI support (drop patch#14 from last version)
* Make patch#15 from last series be patch#1 (vpmu init cleanup)
* Other changes are listed per patch


Changes in v18:

* Return 1 (i.e. "handled") in vpmu_do_interrupt() if PMU_CACHED is
  set. This is needed since we can get an interrupt while this flag is
  set on AMD processors when multiple counters are in use (**) (AMD
  processor don't mask LVTPC when PMC interrupt happens and so there
  is a window in vpmu_do_interrupt() until it sets the mask
  bit). Patch #14
* Unload both current and last_vcpu (if different) vpmu and clear
  this_cpu(last_vcpu) in vpmu_unload_all. Patch #5
* Make major version check for certain xenpmu_ops. Patch #5
* Make xenpmu_op()'s first argument unsigned. Patch #5
* Don't use format specifier for __stringify(). Patch #6
* Don't print generic error in vpmu_init(). Patch #6
* Don't test for VPMU existance in vpmu_initialise(). New patch #15
* Added vpmu_disabled flag to make sure VPMU doesn't get reenabled from
  dom0 (for example when watchdog is active). Patch #5
* Updated tags on some patches to better reflect latest reviewed status)

(**) While testing this I discovered that AMD VPMU is quite broken for
HVM: when multiple counters are in use linux dom0 often gets
unexpected NMIs. This may have something to do with what I mentioned
in the first bullet. However, this doesn't appear to be related to
this patch series (or earlier VPMU patches) --- I can reproduce this
all the way back to 4.1

Changes in v17:
* Disable VPMU when unknown CPU vendor is detected (patch #2)
* Remove unnecessary vendor tests in vendor-specific init routines (patch #14)
* Remember first CPU that starts mode change and use it to stop the cycle 
(patch #13)
* If vpmu ops is not present, return 0 as value for VPMU MSR read (as opposed 
to 
  returning an error as was the case in previous patch.) (patch #18)
  * Change slightly vpmu_do_msr() logic as result of this chage (patch #20)
* stringify VPMU version (patch #14)
* Use 'CS > 1' to mark sample as PMU_SAMPLE_USER (patch #19)

Changes in v16:

* Many changes in VPMU mode patch (#13):
  * Replaced arguments to some vpmu routines (vcpu -> vpmu). New patch (#12)
  * Added vpmu_unload vpmu op to completely unload vpmu data (e.g clear
MSR bitmaps). This routine may be called in context switch 
(vpmu_switch_to()).
  * Added vmx_write_guest_msr_vcpu() interface to write MSRs of non-current VCPU
  * Use cpumask_cycle instead of cpumask_next
  * Dropped timeout error
  * Adjusted types of mode variables
  * Don't allow oprofile to allocate its context on MSR access if VPMU context
has already been allocated (which may happen when VMPU mode was set to off
while the guest was running)
* vpmu_initialise() no longer turns off VPMU globally on failure. New patch (#2)
* vpmu_do_msr() will return 1 (failure) if vpmu_ops are not set. This is done to
  prevent PV guests that are not VPMU-enabled from wrongly assuming that they 
have
  access to counters (Linux check_hw_exists() will make this assumption) (patch 
#18)
* Add cpl field to shared structure that will be passed for HVM guests' samples
  (instead of PMU_SAMPLE_USER flag). Add PMU_SAMPLE_PV flag to mark whose sample
  is passed up. (Patches ## 10, 19, 22)

Changes in v15:

* Rewrote vpmu_force_context_switch() to use continue_hypercall_on_cpu()
* Added vpmu_init initcall that will call vendor-specific init routines
* Added a lock to vpmu_struct to serialize pmu_init()/pmu_finish()
* Use SS instead of CS for DPL (instead of RPL)
* Don't take lock for XENPMU_mode_get
* Make vmpu_mode/features an unsigned int (from uint64_t)
* Adjusted pvh_hypercall64_table[] order
* Replaced address range check [XEN_VIRT_START..XEN_VIRT_END] with

[Xen-devel] [PATCH v22 09/14] x86/VPMU: Add support for PMU register handling on PV guests

[Boris Ostrovsky]

Intercept accesses to PMU MSRs and process them in VPMU module. If vpmu ops
for VCPU are not initialized (which is the case, for example, for PV guests that
are not "VPMU-enlightened") access to MSRs will return failure.

Dump VPMU state for all domains (HVM and PV) when requested.

Signed-off-by: Boris Ostrovsky 
Acked-by: Jan Beulich 
Acked-by: Kevin Tian 
Reviewed-by: Dietmar Hahn 
Tested-by: Dietmar Hahn 
---
 xen/arch/x86/domain.c |  3 +--
 xen/arch/x86/hvm/vmx/vpmu_core2.c | 49 +++--
 xen/arch/x86/hvm/vpmu.c   |  3 +++
 xen/arch/x86/traps.c  | 51 +--
 4 files changed, 95 insertions(+), 11 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index d7f78aa..cd2e258 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -2069,8 +2069,7 @@ void arch_dump_vcpu_info(struct vcpu *v)
 {
 paging_dump_vcpu_info(v);
 
-if ( is_hvm_vcpu(v) )
-vpmu_dump(v);
+vpmu_dump(v);
 }
 
 void domain_cpuid(
diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c 
b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index 4d28c90..e5478a1 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -299,12 +300,18 @@ static inline void __core2_vpmu_save(struct vcpu *v)
 rdmsrl(MSR_CORE_PERF_FIXED_CTR0 + i, fixed_counters[i]);
 for ( i = 0; i < arch_pmc_cnt; i++ )
 rdmsrl(MSR_IA32_PERFCTR0 + i, xen_pmu_cntr_pair[i].counter);
+
+if ( !has_hvm_container_vcpu(v) )
+rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS, core2_vpmu_cxt->global_status);
 }
 
 static int core2_vpmu_save(struct vcpu *v)
 {
 struct vpmu_struct *vpmu = vcpu_vpmu(v);
 
+if ( !has_hvm_container_vcpu(v) )
+wrmsrl(MSR_CORE_PERF_GLOBAL_CTRL, 0);
+
 if ( !vpmu_are_all_set(vpmu, VPMU_CONTEXT_SAVE | VPMU_CONTEXT_LOADED) )
 return 0;
 
@@ -342,6 +349,13 @@ static inline void __core2_vpmu_load(struct vcpu *v)
 wrmsrl(MSR_CORE_PERF_FIXED_CTR_CTRL, core2_vpmu_cxt->fixed_ctrl);
 wrmsrl(MSR_IA32_DS_AREA, core2_vpmu_cxt->ds_area);
 wrmsrl(MSR_IA32_PEBS_ENABLE, core2_vpmu_cxt->pebs_enable);
+
+if ( !has_hvm_container_vcpu(v) )
+{
+wrmsrl(MSR_CORE_PERF_GLOBAL_OVF_CTRL, core2_vpmu_cxt->global_ovf_ctrl);
+core2_vpmu_cxt->global_ovf_ctrl = 0;
+wrmsrl(MSR_CORE_PERF_GLOBAL_CTRL, core2_vpmu_cxt->global_ctrl);
+}
 }
 
 static void core2_vpmu_load(struct vcpu *v)
@@ -433,7 +447,6 @@ static int core2_vpmu_msr_common_check(u32 msr_index, int 
*type, int *index)
 static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
uint64_t supported)
 {
-u64 global_ctrl;
 int i, tmp;
 int type = -1, index = -1;
 struct vcpu *v = current;
@@ -477,7 +490,12 @@ static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t 
msr_content,
 switch ( msr )
 {
 case MSR_CORE_PERF_GLOBAL_OVF_CTRL:
+if ( msr_content & ~(0xC000 |
+ (((1ULL << fixed_pmc_cnt) - 1) << 32) |
+ ((1ULL << arch_pmc_cnt) - 1)) )
+return 1;
 core2_vpmu_cxt->global_status &= ~msr_content;
+wrmsrl(MSR_CORE_PERF_GLOBAL_OVF_CTRL, msr_content);
 return 0;
 case MSR_CORE_PERF_GLOBAL_STATUS:
 gdprintk(XENLOG_INFO, "Can not write readonly MSR: "
@@ -505,14 +523,18 @@ static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t 
msr_content,
 gdprintk(XENLOG_WARNING, "Guest setting of DTS is ignored.\n");
 return 0;
 case MSR_CORE_PERF_GLOBAL_CTRL:
-global_ctrl = msr_content;
+core2_vpmu_cxt->global_ctrl = msr_content;
 break;
 case MSR_CORE_PERF_FIXED_CTR_CTRL:
 if ( msr_content &
  ( ~((1ull << (fixed_pmc_cnt * FIXED_CTR_CTRL_BITS)) - 1)) )
 return 1;
 
-vmx_read_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL, &global_ctrl);
+if ( has_hvm_container_vcpu(v) )
+vmx_read_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL,
+   &core2_vpmu_cxt->global_ctrl);
+else
+rdmsrl(MSR_CORE_PERF_GLOBAL_CTRL, core2_vpmu_cxt->global_ctrl);
 *enabled_cntrs &= ~(((1ULL << fixed_pmc_cnt) - 1) << 32);
 if ( msr_content != 0 )
 {
@@ -537,7 +559,11 @@ static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t 
msr_content,
 if ( msr_content & (~((1ull << 32) - 1)) )
 return 1;
 
-vmx_read_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL, &global_ctrl);
+if ( has_hvm_container_vcpu(v) )
+vmx_read_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL,
+   &core2_vpmu_cxt->global_ctrl);
+else
+rdmsrl(MSR_CORE_PERF_GLOBAL_CTRL, core2_vpmu_cxt->global_ctrl);
 
 if ( msr_content & (1ULL <

[Xen-devel] [PATCH v22 13/14] x86/VPMU: Add privileged PMU mode

[Boris Ostrovsky]

Add support for privileged PMU mode (XENPMU_MODE_ALL) which allows privileged
domain (dom0) profile both itself (and the hypervisor) and the guests. While
this mode is on profiling in guests is disabled.

Signed-off-by: Boris Ostrovsky 
Acked-by: Jan Beulich 
---
 xen/arch/x86/hvm/vpmu.c  | 40 +---
 xen/arch/x86/traps.c | 13 +
 xen/include/public/pmu.h |  3 +++
 3 files changed, 45 insertions(+), 11 deletions(-)

diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index a7b4dcb..2eb369c 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -108,8 +108,10 @@ int vpmu_do_msr(unsigned int msr, uint64_t *msr_content,
 const struct arch_vpmu_ops *ops;
 int ret = 0;
 
-if ( likely(vpmu_mode == XENPMU_MODE_OFF) )
-goto nop;
+if ( likely(vpmu_mode == XENPMU_MODE_OFF) ||
+ ((vpmu_mode & XENPMU_MODE_ALL) &&
+  !is_hardware_domain(current->domain)) )
+ goto nop;
 
 vpmu = vcpu_vpmu(curr);
 ops = vpmu->arch_vpmu_ops;
@@ -164,8 +166,12 @@ void vpmu_do_interrupt(struct cpu_user_regs *regs)
 struct vlapic *vlapic;
 u32 vlapic_lvtpc;
 
-/* dom0 will handle interrupt for special domains (e.g. idle domain) */
-if ( sampled->domain->domain_id >= DOMID_FIRST_RESERVED )
+/*
+ * dom0 will handle interrupt for special domains (e.g. idle domain) or,
+ * in XENPMU_MODE_ALL, for everyone.
+ */
+if ( (vpmu_mode & XENPMU_MODE_ALL) ||
+ (sampled->domain->domain_id >= DOMID_FIRST_RESERVED) )
 {
 sampling = choose_hwdom_vcpu();
 if ( !sampling )
@@ -179,16 +185,17 @@ void vpmu_do_interrupt(struct cpu_user_regs *regs)
 return;
 
 /* PV(H) guest */
-if ( !is_hvm_vcpu(sampling) )
+if ( !is_hvm_vcpu(sampling) || (vpmu_mode & XENPMU_MODE_ALL) )
 {
 const struct cpu_user_regs *cur_regs;
 uint64_t *flags = &vpmu->xenpmu_data->pmu.pmu_flags;
-domid_t domid = DOMID_SELF;
+domid_t domid;
 
 if ( !vpmu->xenpmu_data )
 return;
 
 if ( is_pvh_vcpu(sampling) &&
+ !(vpmu_mode & XENPMU_MODE_ALL) &&
  !vpmu->arch_vpmu_ops->do_interrupt(regs) )
 return;
 
@@ -205,6 +212,11 @@ void vpmu_do_interrupt(struct cpu_user_regs *regs)
 else
 *flags = PMU_SAMPLE_PV;
 
+if ( sampled == sampling )
+domid = DOMID_SELF;
+else
+domid = sampled->domain->domain_id;
+
 /* Store appropriate registers in xenpmu_data */
 /* FIXME: 32-bit PVH should go here as well */
 if ( is_pv_32bit_vcpu(sampling) )
@@ -233,7 +245,8 @@ void vpmu_do_interrupt(struct cpu_user_regs *regs)
 
 if ( (vpmu_mode & XENPMU_MODE_SELF) )
 cur_regs = guest_cpu_user_regs();
-else if ( !guest_mode(regs) && 
is_hardware_domain(sampling->domain) )
+else if ( !guest_mode(regs) &&
+  is_hardware_domain(sampling->domain) )
 {
 cur_regs = regs;
 domid = DOMID_XEN;
@@ -469,7 +482,9 @@ void vpmu_initialise(struct vcpu *v)
 printk(XENLOG_G_WARNING "VPMU: Initialization failed for %pv\n", v);
 
 /* Intel needs to initialize VPMU ops even if VPMU is not in use */
-if ( !is_priv_vpmu && (ret || (vpmu_mode == XENPMU_MODE_OFF)) )
+if ( !is_priv_vpmu &&
+ (ret || (vpmu_mode == XENPMU_MODE_OFF) ||
+  (vpmu_mode == XENPMU_MODE_ALL)) )
 {
 spin_lock(&vpmu_lock);
 vpmu_count--;
@@ -522,7 +537,8 @@ static int pvpmu_init(struct domain *d, xen_pmu_params_t 
*params)
 struct page_info *page;
 uint64_t gfn = params->val;
 
-if ( vpmu_mode == XENPMU_MODE_OFF )
+if ( (vpmu_mode == XENPMU_MODE_OFF) ||
+ ((vpmu_mode & XENPMU_MODE_ALL) && !is_hardware_domain(d)) )
 return -EINVAL;
 
 if ( (params->vcpu >= d->max_vcpus) || (d->vcpu[params->vcpu] == NULL) )
@@ -642,12 +658,14 @@ long do_xenpmu_op(unsigned int op, 
XEN_GUEST_HANDLE_PARAM(xen_pmu_params_t) arg)
 {
 case XENPMU_mode_set:
 {
-if ( (pmu_params.val & ~(XENPMU_MODE_SELF | XENPMU_MODE_HV)) ||
+if ( (pmu_params.val &
+  ~(XENPMU_MODE_SELF | XENPMU_MODE_HV | XENPMU_MODE_ALL)) ||
  (hweight64(pmu_params.val) > 1) )
 return -EINVAL;
 
 /* 32-bit dom0 can only sample itself. */
-if ( is_pv_32bit_vcpu(current) && (pmu_params.val & XENPMU_MODE_HV) )
+if ( is_pv_32bit_vcpu(current) &&
+ (pmu_params.val & (XENPMU_MODE_HV | XENPMU_MODE_ALL)) )
 return -EINVAL;
 
 spin_lock(&vpmu_lock);
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 5d4d07a..b4215f7 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -2653,6 +2653,10 @@ static int emulate_privileged_op(struct cpu_user_regs 
*regs)
 case MSR_AMD_FAM15H_EVNTSEL0...MSR_AMD_FAM15H_PERFCTR

[Xen-devel] [PATCH v22 05/14] x86/VPMU: Initialize VPMUs with __initcall

[Boris Ostrovsky]

Move some VPMU initilization operations into __initcalls to avoid performing
same tests and calculations for each vcpu.

Signed-off-by: Boris Ostrovsky 
Acked-by: Jan Beulich 
---
 xen/arch/x86/hvm/svm/vpmu.c   | 106 --
 xen/arch/x86/hvm/vmx/vpmu_core2.c | 151 +++---
 xen/arch/x86/hvm/vpmu.c   |  32 
 xen/include/asm-x86/hvm/vpmu.h|   2 +
 4 files changed, 156 insertions(+), 135 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index 481ea7b..b60ca40 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -356,54 +356,6 @@ static int amd_vpmu_do_rdmsr(unsigned int msr, uint64_t 
*msr_content)
 return 1;
 }
 
-static int amd_vpmu_initialise(struct vcpu *v)
-{
-struct xen_pmu_amd_ctxt *ctxt;
-struct vpmu_struct *vpmu = vcpu_vpmu(v);
-uint8_t family = current_cpu_data.x86;
-
-if ( counters == NULL )
-{
- switch ( family )
-{
-case 0x15:
-num_counters = F15H_NUM_COUNTERS;
-counters = AMD_F15H_COUNTERS;
-ctrls = AMD_F15H_CTRLS;
-k7_counters_mirrored = 1;
-break;
-case 0x10:
-case 0x12:
-case 0x14:
-case 0x16:
-default:
-num_counters = F10H_NUM_COUNTERS;
-counters = AMD_F10H_COUNTERS;
-ctrls = AMD_F10H_CTRLS;
-k7_counters_mirrored = 0;
-break;
-}
-}
-
-ctxt = xzalloc_bytes(sizeof(*ctxt) +
- 2 * sizeof(uint64_t) * num_counters);
-if ( !ctxt )
-{
-gdprintk(XENLOG_WARNING, "Insufficient memory for PMU, "
-" PMU feature is unavailable on domain %d vcpu %d.\n",
-v->vcpu_id, v->domain->domain_id);
-return -ENOMEM;
-}
-
-ctxt->counters = sizeof(*ctxt);
-ctxt->ctrls = ctxt->counters + sizeof(uint64_t) * num_counters;
-
-vpmu->context = ctxt;
-vpmu->priv_context = NULL;
-vpmu_set(vpmu, VPMU_CONTEXT_ALLOCATED);
-return 0;
-}
-
 static void amd_vpmu_destroy(struct vcpu *v)
 {
 struct vpmu_struct *vpmu = vcpu_vpmu(v);
@@ -474,30 +426,62 @@ struct arch_vpmu_ops amd_vpmu_ops = {
 
 int svm_vpmu_initialise(struct vcpu *v)
 {
+struct xen_pmu_amd_ctxt *ctxt;
 struct vpmu_struct *vpmu = vcpu_vpmu(v);
-uint8_t family = current_cpu_data.x86;
-int ret = 0;
 
-/* vpmu enabled? */
 if ( vpmu_mode == XENPMU_MODE_OFF )
 return 0;
 
-switch ( family )
+if ( !counters )
+return -EINVAL;
+
+ctxt = xzalloc_bytes(sizeof(*ctxt) +
+ 2 * sizeof(uint64_t) * num_counters);
+if ( !ctxt )
 {
+printk(XENLOG_G_WARNING "Insufficient memory for PMU, "
+   " PMU feature is unavailable on domain %d vcpu %d.\n",
+   v->vcpu_id, v->domain->domain_id);
+return -ENOMEM;
+}
+
+ctxt->counters = sizeof(*ctxt);
+ctxt->ctrls = ctxt->counters + sizeof(uint64_t) * num_counters;
+
+vpmu->context = ctxt;
+vpmu->priv_context = NULL;
+
+vpmu->arch_vpmu_ops = &amd_vpmu_ops;
+
+vpmu_set(vpmu, VPMU_CONTEXT_ALLOCATED);
+return 0;
+}
+
+int __init amd_vpmu_init(void)
+{
+switch ( current_cpu_data.x86 )
+{
+case 0x15:
+num_counters = F15H_NUM_COUNTERS;
+counters = AMD_F15H_COUNTERS;
+ctrls = AMD_F15H_CTRLS;
+k7_counters_mirrored = 1;
+break;
 case 0x10:
 case 0x12:
 case 0x14:
-case 0x15:
 case 0x16:
-ret = amd_vpmu_initialise(v);
-if ( !ret )
-vpmu->arch_vpmu_ops = &amd_vpmu_ops;
-return ret;
+num_counters = F10H_NUM_COUNTERS;
+counters = AMD_F10H_COUNTERS;
+ctrls = AMD_F10H_CTRLS;
+k7_counters_mirrored = 0;
+break;
+default:
+printk(XENLOG_WARNING "VPMU: Unsupported CPU family %#x\n",
+   current_cpu_data.x86);
+return -EINVAL;
 }
 
-printk("VPMU: Initialization failed. "
-   "AMD processor family %d has not "
-   "been supported\n", family);
-return -EINVAL;
+return 0;
 }
 
diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c 
b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index 9dca51b..1d301a2 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -708,62 +708,6 @@ static int core2_vpmu_do_interrupt(struct cpu_user_regs 
*regs)
 return 1;
 }
 
-static int core2_vpmu_initialise(struct vcpu *v)
-{
-struct vpmu_struct *vpmu = vcpu_vpmu(v);
-u64 msr_content;
-static bool_t ds_warned;
-
-if ( !(vpmu_features & XENPMU_FEATURE_INTEL_BTS) )
-goto func_out;
-/* Check the 'Debug Store' feature in the CPUID.EAX[1]:EDX[21] */
-while ( boot_cpu_has(X86_FEATURE_DS) )
-{
-if ( !boot_cpu_has(X86_FEATURE_DTES64) )
-{
-if ( !ds_warned )
-printk(XENLOG_G_WARNING "CPU does

[Xen-devel] [PATCH v22 03/14] x86/VPMU: Make vpmu not HVM-specific

[Boris Ostrovsky]

vpmu structure will be used for both HVM and PV guests. Move it from
hvm_vcpu to arch_vcpu.

Signed-off-by: Boris Ostrovsky 
Acked-by: Jan Beulich 
Reviewed-by: Kevin Tian 
Reviewed-by: Dietmar Hahn 
Tested-by: Dietmar Hahn 
---
 xen/include/asm-x86/domain.h   | 2 ++
 xen/include/asm-x86/hvm/vcpu.h | 3 ---
 xen/include/asm-x86/hvm/vpmu.h | 5 ++---
 3 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
index 45b5283..ba5875a 100644
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -452,6 +452,8 @@ struct arch_vcpu
 void (*ctxt_switch_from) (struct vcpu *);
 void (*ctxt_switch_to) (struct vcpu *);
 
+struct vpmu_struct vpmu;
+
 /* Virtual Machine Extensions */
 union {
 struct pv_vcpu pv_vcpu;
diff --git a/xen/include/asm-x86/hvm/vcpu.h b/xen/include/asm-x86/hvm/vcpu.h
index 3d8f4dc..0faf60d 100644
--- a/xen/include/asm-x86/hvm/vcpu.h
+++ b/xen/include/asm-x86/hvm/vcpu.h
@@ -151,9 +151,6 @@ struct hvm_vcpu {
 u32 msr_tsc_aux;
 u64 msr_tsc_adjust;
 
-/* VPMU */
-struct vpmu_struct  vpmu;
-
 union {
 struct arch_vmx_struct vmx;
 struct arch_svm_struct svm;
diff --git a/xen/include/asm-x86/hvm/vpmu.h b/xen/include/asm-x86/hvm/vpmu.h
index 83eea7e..82bfa0e 100644
--- a/xen/include/asm-x86/hvm/vpmu.h
+++ b/xen/include/asm-x86/hvm/vpmu.h
@@ -31,9 +31,8 @@
 #define VPMU_BOOT_ENABLED 0x1/* vpmu generally enabled. */
 #define VPMU_BOOT_BTS 0x2/* Intel BTS feature wanted. */
 
-#define vcpu_vpmu(vcpu)   (&((vcpu)->arch.hvm_vcpu.vpmu))
-#define vpmu_vcpu(vpmu)   (container_of((vpmu), struct vcpu, \
-  arch.hvm_vcpu.vpmu))
+#define vcpu_vpmu(vcpu)   (&(vcpu)->arch.vpmu)
+#define vpmu_vcpu(vpmu)   container_of((vpmu), struct vcpu, arch.vpmu)
 
 #define MSR_TYPE_COUNTER0
 #define MSR_TYPE_CTRL   1
-- 
1.8.1.4


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

[Xen-devel] [PATCH v22 07/14] x86/VPMU: Save VPMU state for PV guests during context switch

[Boris Ostrovsky]

Save VPMU state during context switch for both HVM and PV(H) guests.

A subsequent patch ("x86/VPMU: NMI-based VPMU support") will make it possible
for vpmu_switch_to() to call vmx_vmcs_try_enter()->vcpu_pause() which needs
is_running to be correctly set/cleared. To prepare for that, call 
context_saved()
before vpmu_switch_to() is executed. (Note that while this change could have
been dalayed until that later patch, the changes are harmless to existing code
and so we do it here)

Signed-off-by: Boris Ostrovsky 
Reviewed-by: Jan Beulich 
---
 xen/arch/x86/domain.c | 22 ++
 1 file changed, 10 insertions(+), 12 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 6ff70ea..d7f78aa 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1537,17 +1537,14 @@ void context_switch(struct vcpu *prev, struct vcpu 
*next)
 }
 
 if ( prev != next )
-_update_runstate_area(prev);
-
-if ( is_hvm_vcpu(prev) )
 {
-if (prev != next)
-vpmu_switch_from(prev);
-
-if ( !list_empty(&prev->arch.hvm_vcpu.tm_list) )
-pt_save_timer(prev);
+_update_runstate_area(prev);
+vpmu_switch_from(prev);
 }
 
+if ( is_hvm_vcpu(prev) && !list_empty(&prev->arch.hvm_vcpu.tm_list) )
+pt_save_timer(prev);
+
 local_irq_disable();
 
 set_current(next);
@@ -1585,15 +1582,16 @@ void context_switch(struct vcpu *prev, struct vcpu 
*next)
!is_hardware_domain(next->domain));
 }
 
-if (is_hvm_vcpu(next) && (prev != next) )
-/* Must be done with interrupts enabled */
-vpmu_switch_to(next);
-
 context_saved(prev);
 
 if ( prev != next )
+{
 _update_runstate_area(next);
 
+/* Must be done with interrupts enabled */
+vpmu_switch_to(next);
+}
+
 /* Ensure that the vcpu has an up-to-date time base. */
 update_vcpu_system_time(next);
 
-- 
1.8.1.4


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

Re: [Xen-devel] [PATCH RFC v1] libxl: Introduce a template for devices with a controller

[George Dunlap]

On 05/21/2015 06:07 PM, George Dunlap wrote:
> We have several outstanding patch series which add devices that have
> two levels: a controller and individual devices attached to that
> controller.
> 
> In the interest of consistency, this patch introduces a section that
> sketches out a template for interfaces for such devices.
> 
> Signed-off-by: George Dunlap 
> ---
> CC: Ian Campbell 
> CC: Ian Jackson 
> CC: Wei Liu 
> CC: Juergen Gross 
> CC: Chun Yan Liu 
> CC: Olaf Hering 
> 
> So, this is definitely RFC -- I tried to spec things out in a way that
> made sense, but I often just chose something that I thought would be a
> sensible starting point for discussion.
> 
> This spec looks a lot more like the PVUSB spec than the PVSCSI spec,
> in part because I think the PVUSB spec has already had a lot more
> thought that's gone into it.
> 
> A couple of random points to discuss:
> 
> * Calling things "controllers", using ctrl for the device name,
>   and using "ctrl" as the field name for the devid of the controller
>   in the individual devices.
> 
> * I've said that having an index (port, lun, whatever) is optional.
>   Do we want to make that requred?  Do we want it to have a consistent
>   name?  In the case of emulated USB, we can't really specify to qemu
>   what port the device gets attached to, so I'm tempted to say it's
>   not required; but even there we could always give it a port number
>   just for name's sake.
> 
> * Naming sub-devices.  We need to have a way to uniquely name both
>   controllers and subdevices.  Here I've said that we will have both
>   ctrl and  devid namespaces, mainly because in the
>   previous point I opted not to require an index.  Another option
>   would be not to have another devid namespace, but to use
>as the unique identifier.  (This would mean requiring
>   the index/port/lun specification above.)
> 
> * libxl_device__list listing devices across all controllers.  I
>   think this is the most practical thing to do, but one could imagine
>   wanting to query by controller ID instead.
> 
> Feedback welcome.
> ---
>  tools/libxl/libxl.h | 46 ++
>  1 file changed, 46 insertions(+)
> 
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index 2ed7194..d757845 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -1234,6 +1234,52 @@ void libxl_vtpminfo_list_free(libxl_vtpminfo *, int 
> nr_vtpms);
>   *
>   *   This function does not interact with the guest and therefore
>   *   cannot block on the guest.
> + *
> + * Controllers
> + * ---
> + *
> + * Most devices are treated individually.  Some devices however, like
> + * USB or SCSI, inherently have the need to have "busses" or
> + * "controllers" to which individual devices can be attached.
> + *
> + * In that case, for each , there will be two sets of the
> + * functions, types, and devid namespaces outlined above: one based on
> + * '', and one based on 'ctrl'.
> + *
> + * In those cases, libxl_device_ctrl_ will act more or
> + * less like top-level non-bus devices: they will either create or
> + * accept a libxl_devid which will be unique within the
> + * ctrl libxl_devid namespace.
> + *
> + * Second-level devices which will be attached to a controller will
> + * include in their libxl_device_ a field called ctrl, which
> + * will be the libxl_devid of the corresponding controller.  It may also
> + * include an index onto that bus, that represents (for example) a USB
> + * port or a SCSI LUN.
> + *
> + * These second-level devices will also have their own devid which
> + * will be unique within the  devid namespace, and will be used
> + * for queries or removals.
> + *
> + * In the case where there are multiple different ways to implement a
> + * given device -- for instance, one which is fully PV and one which
> + * uses an emulator -- the controller will contain a field which
> + * specifies what type of implementation is used.  The implementations
> + * of individual devices will be known by the controller to which they are
> + * attached.
> + *
> + * If libxl_device__add receives an uninitialized ctrl devid, it
> + * may return an error.  Or it may (but is not required to) choose to
> + * automatically choose a suitable controller to which to attach the
> + * new device.  It may also (but is not required to) automatically
> + * create a new controller if no suitable controllers exist.
> + * Individual devices should document their behavior.
> + *
> + * libxl_device_ctrl_list will list all controllers for the domain.
> + *
> + * libxl_device__list will list all devices for all controllers
> + * for the domain.  The individual libxl_device_ will include
> + * the devid of the controller to which it is attached.
>   */

So just for concreteness, here is a somewhat "dumb" conversion of the
most recently-posted pvscsi IDL using this template:

libxl_vscsi_pdev_type = Enumeration("vscsi_pdev_type", [
(0, "INVALID"),
(1, "HCTL"),
   

Re: [Xen-devel] [PATCH] xl: Support (by ignoring) xl migrate --live

[Olaf Hering]

On Thu, May 21, Ian Campbell wrote:

> My pod2text doesn't seem to complain, but does this help?

Yes, this fixes it.

Thanks!

> Subject: [PATCH] docs: correct pod syntax

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

[Xen-devel] [linux-3.4 test] 56886: regressions - FAIL

[osstest service user]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl   9 debian-install fail REGR. vs. 52209-bisect
 test-amd64-amd64-pair   15 debian-install/dst_host fail REGR. vs. 52715-bisect
 test-amd64-i386-pair15 debian-install/dst_host fail REGR. vs. 56366-bisect

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-libvirt   9 debian-installfail blocked in 56366-bisect
 test-amd64-amd64-xl-sedf  9 debian-installfail blocked in 56366-bisect
 test-amd64-amd64-libvirt  9 debian-installfail blocked in 56366-bisect
 test-amd64-amd64-xl-multivcpu  6 xen-boot fail blocked in 56366-bisect
 test-amd64-i386-libvirt-xsm   6 xen-boot  fail blocked in 56366-bisect
 test-amd64-i386-qemut-rhel6hvm-intel  6 xen-boot  fail blocked in 56366-bisect
 test-amd64-i386-freebsd10-amd64  6 xen-boot   fail blocked in 56366-bisect
 test-amd64-i386-xl9 debian-installfail blocked in 56366-bisect
 test-amd64-amd64-xl-sedf-pin  9 debian-installfail blocked in 56366-bisect
 test-amd64-i386-rumpuserxen-i386  6 xen-boot  fail blocked in 56366-bisect
 test-amd64-i386-xl-qemuu-winxpsp3  6 xen-boot fail blocked in 56366-bisect
 test-amd64-i386-xl-qemut-debianhvm-amd64 6 xen-boot fail blocked in 
56366-bisect
 test-amd64-amd64-rumpuserxen-amd64  6 xen-bootfail blocked in 56366-bisect
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 6 xen-boot fail blocked in 
56366-bisect
 test-amd64-i386-xl-qemuu-ovmf-amd64  6 xen-boot   fail blocked in 56366-bisect
 test-amd64-i386-xl-qemuu-debianhvm-amd64 6 xen-boot fail blocked in 
56366-bisect
 test-amd64-i386-qemuu-rhel6hvm-intel  6 xen-boot  fail blocked in 56366-bisect
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail blocked in 56366-bisect
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail blocked in 56366-bisect
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail blocked in 56366-bisect
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 6 xen-boot fail blocked in 
56366-bisect
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 6 xen-boot fail blocked in 
56366-bisect
 test-amd64-amd64-xl-qemut-debianhvm-amd64 6 xen-boot fail blocked in 
56366-bisect
 test-amd64-amd64-xl-qemuu-ovmf-amd64  6 xen-bootfail like 53709-bisect

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail never 
pass
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail never 
pass
 test-amd64-amd64-xl-credit2   9 debian-install   fail   never pass
 test-amd64-amd64-xl-pvh-amd   9 debian-install   fail   never pass
 test-amd64-i386-xl-xsm9 debian-install   fail   never pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail never 
pass
 test-amd64-amd64-xl-pvh-intel  9 debian-install   fail  never pass
 test-amd64-amd64-libvirt-xsm  9 debian-install   fail   never pass
 test-amd64-amd64-xl-xsm   9 debian-install   fail   never pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail never 
pass
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail never pass

version targeted for testing:
 linux56b48fcda5076d4070ab00df32ff5ff834e0be86
baseline version:
 linuxbb4a05a0400ed6d2f1e13d1f82f289ff74300a70


370 people touched revisions under test,
not listing them all


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
 build-amd64-rumpuserxen  pass
 build-i386-rumpuserxen   pass
 test-amd64-amd64-xl  fail
 test-amd64-i386-xl   fail
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsmfail
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm fail
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmfail
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm fail
 test-amd64-amd64-libvirt-xsm fail
 test-amd64-i386-libvirt-xsm 

Re: [Xen-devel] [linux-next test] 56810: regressions - FAIL

[Ian Campbell]

On Thu, 2015-05-21 at 16:24 +0100, Ian Campbell wrote:
> Figuring this out will probably involve a few adhoc test runs to
> establish some baselines and then taking it from there.

I've kicked off an adhoc test (hopefully correctly) of v3.14 using the
template failure from flight 31795. It's easiest to do this in the
Cambridge instance because that has the oldest (and therefore nearest
the actual bug) flight.

I had to bodge it slightly by changing the freebsd_image to a raw one
since the templates used a qcow2 but the current harness seems to no
longer support that.

Assuming this flight produces something useful (i.e. a pass) then I'll
look into a bisect.

Ian.


http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-i386-freebsd10-amd64.linux-linus.html

oldest fail in 31795 Linux 8a84e01e147f, on leaf-beetle
$ git describe --contains 8a84e01e147f
v3.18-rc6~9

http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-i386-freebsd10-amd64.linux-3.14.html
closest pass to mainline is the first one in flight 29572 Linux
735fbc72bee7, on bush-cricket
(later ones are v3.14.X for X > 16, i.e. further from Linus' mainline)

$ git describe --contains 735fbc72bee7
v3.14.15^0

$ git merge-base 8a84e01e147f 735fbc72bee7
455c6fdbd219161bd09b1165f11699d6d73de11c
$ git describe --contains 455c6fdbd219161bd09b1165f11699d6d73de11c
v3.14^0

flight=`./cs-flight-create adhoc linux-linus`
echo $flight
./cs-adjust-flight $flight copy-jobs 31795 test-amd64-i386-freebsd10-amd64
./cs-adjust-flight $flight copy-jobs 31795 build-i386
./cs-adjust-flight $flight copy-jobs 31795 build-amd64
./cs-adjust-flight $flight copy-jobs 31795 build-i386-pvops
./cs-adjust-flight $flight runvar-set test-amd64-i386-freebsd10-amd64 host 
leaf-beetle
./cs-adjust-flight $flight runvar-set test-amd64-i386-freebsd10-amd64 
freebsd_image FreeBSD-10.1-RELEASE-amd64.raw.xz
./cs-adjust-flight $flight runvar-set build-i386-pvops revision_linux 
455c6fdbd219161bd09b1165f11699d6d73de11c
./mg-execute-flight -Badhoc -eian.campb...@citrix.com,roger@citrix.com 
$flight



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

Re: [Xen-devel] RFC: Proposal to improve error reporting in libxl

[Ian Campbell]

On Wed, 2015-05-20 at 10:01 +0100, Euan Harris wrote:
> We would like to make libxl's error reporting more regular and informative
> for callers.

Yes, I agree this is a good idea.

> We think we need to:
> 
>   * Make a list of the error conditions which can be encountered by
> all the current API calls and define a set of error codes to
> cover them.   Some codes will be generally applicable, but give
> more information than a bare 'fail'; others may be specific to a
> particular API call.   We may keep the existing FAIL, INVAL and 
> NOMEM codes for times when they are appropriate.
> 
> The error messages logged by each API call are a good starting point
> for this list.   I have included a partial list below.
> 
>   * Change the API calls in point 1 above to use the new, more detailed
> error codes.   These changes will break client code which checks for
> particular error codes, rather than just checking whether the return
> code is non-zero.

I think that at least for the case of turning a uselessly generic
ERROR_FAIL into something specific this is tolerable.

I'm not sure if we will want a raft of LIBXL_HAVE_ERROR_* defines. It
seems not all that useful.

(Perhaps every enum value FOO in the IDL should get a #define FOO FOO to
make this automatic?)

>   * For the API calls in points 2 and 3 which can encounter errors
> which callers might care about, change their interfaces to return
> error codes.   For functions which previously returned pointers,
> add pointer-to-pointer parameters.

I think this is doable using the LIBXL_API_VERSION arrangements
(described in libxl.h)

Essential for an existing
THING *get_a_thing_list(ctx, int *nr_r)
which you are converting to
int get_a_thing_list(ctx, THING **list_r, int *nr_r)

you would do something like:

#if LIBXL_API_VERSION < 0x406000 /* or whatever version */
static inline THING *get_a_thing_list(ctx, int *nr_r)
{
THING *list = NULL
int rc = get_a_thing_list(ctx, &list, nr_r);
if ( rc )
return NULL
else
return list;
}
#endif

Or something along those lines.

>   * For error codes returned by utility functions, described in point 4, 
> decide whether the code can be reported directly or an API-level
> error should be reported instead.

I think this fits in with the cleanups made in the second bullet and is
likewise fine. (But worth considering separately I agree)

Ian.


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

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

[osstest service user]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail REGR. vs. 56492
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail REGR. vs. 56492

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail never 
pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail never 
pass

version targeted for testing:
 ovmf 4cd67a4d4381982e7af734765bc6103a8afb2bb8
baseline version:
 ovmf f1f0f0deb6e64df6b7c04ead7330afecf5537e46


People who touched revisions under test:
  "Yao, Jiewen" 
  Chao Zhang 
  Eric Dong 
  Feng Tian 
  Guo Dong 
  Hao Wu 
  Jeff Fan 
  jiaxinwu 
  Liming Gao 
  Ruiyu Ni 
  Star Zeng 
  Yao, Jiewen 


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-debianhvm-amd64-xsmfail
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm fail
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-i386-qemuu-rhel6hvm-intel pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
 test-amd64-amd64-xl-qemuu-winxpsp3   pass
 test-amd64-i386-xl-qemuu-winxpsp3pass



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

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


Not pushing.

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

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

Re: [Xen-devel] [PATCH OSSTEST 3/5] Cope with Jessie's d-i vg name

[Wei Liu]

On Thu, May 21, 2015 at 05:15:55PM +0100, Ian Campbell wrote:
> On Thu, 2015-05-21 at 17:04 +0100, Wei Liu wrote:
> > On Thu, May 21, 2015 at 04:10:02PM +0100, Ian Campbell wrote:
> > > On Wed, 2015-05-20 at 18:56 +0100, Wei Liu wrote:
> > > > In ts-xen-build-prep, replace matching lenny with jessie since lenny is
> > > > not used in production anymore.
> > > 
> > > AIUI the default VG name scheme changed? Can you say how here please.
> > > 
> > 
> > Sure.
> > 
> > > Also I think in general we should aim for the "non-exceptional" case to
> > > be the default one, and use explicit matching for issues with historical
> > > versions. IOW test for wheezy and earlier and override the default (i.e.
> > > Jessie) name. The rationale is that we shouldn't need to add Stretch
> > > here too unless it also differs from Jessie.
> > > 
> > > That principal seems to apply to a some of the following patches too.
> > > 
> > > WRT "wheezy and earlier" I've been wondering about providing a function
> > > to transform a Debian code name to a sortable integer. e.g.
> > > 
> > > sub debver($) {
> > > my %vers = qw(Lenny 50
> > >   Squeeze 60
> > >   Wheezy 70
> > >   Jessie 80
> > >   Stretch 90
> > >   Sid 100);
> > > # Unknown is > sid...
> > > return $vers{ucfirst($_[0])) // 101;
> > > }
> > > 
> > > so you can do things like
> > > if ( debver($ho->{Suite}) < debver('jessie') ) {
> > > workaround_a_thing();
> > > 
> > 
> > You would need to test for "$ho->{Suite} == A" or "A < $ho->{Suite} < B".
> 
> if ( debver($ho->{Suite}) <= debver('squeeze') )
> handle Squeeze or earlier
> elseif ( debver($ho->{Suite}) <= debver('wheezy') )
> handle Wheezy
> else
> handle Jessie onwards
> 
> I'm not sure if Perl supports
> debver('squeeze') < debver($ho->{Suite}) <= debver('wheezy')
> like some languages do.
> 

I was just writing pseudo code.

> > And it's just another form of saying "if ($ho->{Suite} =~ /XXX/)" IMHO.
> 
> The difference is you don't need to enumerate all the names. e.g.
> "lenny|squeeze|wheezy" becomes "< debver('wheezy')"
> 
> > > Thoughts?
> > 
> > That would be nice but I doubt it would be of much use -- who
> > doesn't want the latest version in production... ;-)
> 
> People who think it is useful to continue to test Wheezy for some
> reason? People who have other constraints preventing them from upgrading
> right away? People who want to use a _newer_ version for some reason and
> want to make Stretch work while not breaking Wheezy/Jessie for everyone
> else.
> 
> If it were expensive to support I'd agree, but I don't think it is,
> especially if you arrange to never need to touch it again...
> 
> BTW, at some point I'm hoping to extend my distros flight stuff to cover
> testing the distro host packages, at which point it would naturally be
> useful to cover at least current stable and current testing, if not
> oldstable or sid.
> 

Yeah, this is a valid use case for that.

Wei.

> Ian.

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

Re: [Xen-devel] [PATCH OSSTEST 3/5] Cope with Jessie's d-i vg name

[Ian Campbell]

On Thu, 2015-05-21 at 17:04 +0100, Wei Liu wrote:
> On Thu, May 21, 2015 at 04:10:02PM +0100, Ian Campbell wrote:
> > On Wed, 2015-05-20 at 18:56 +0100, Wei Liu wrote:
> > > In ts-xen-build-prep, replace matching lenny with jessie since lenny is
> > > not used in production anymore.
> > 
> > AIUI the default VG name scheme changed? Can you say how here please.
> > 
> 
> Sure.
> 
> > Also I think in general we should aim for the "non-exceptional" case to
> > be the default one, and use explicit matching for issues with historical
> > versions. IOW test for wheezy and earlier and override the default (i.e.
> > Jessie) name. The rationale is that we shouldn't need to add Stretch
> > here too unless it also differs from Jessie.
> > 
> > That principal seems to apply to a some of the following patches too.
> > 
> > WRT "wheezy and earlier" I've been wondering about providing a function
> > to transform a Debian code name to a sortable integer. e.g.
> > 
> > sub debver($) {
> > my %vers = qw(Lenny 50
> >   Squeeze 60
> >   Wheezy 70
> >   Jessie 80
> >   Stretch 90
> >   Sid 100);
> > # Unknown is > sid...
> > return $vers{ucfirst($_[0])) // 101;
> > }
> > 
> > so you can do things like
> > if ( debver($ho->{Suite}) < debver('jessie') ) {
> > workaround_a_thing();
> > 
> 
> You would need to test for "$ho->{Suite} == A" or "A < $ho->{Suite} < B".

if ( debver($ho->{Suite}) <= debver('squeeze') )
handle Squeeze or earlier
elseif ( debver($ho->{Suite}) <= debver('wheezy') )
handle Wheezy
else
handle Jessie onwards

I'm not sure if Perl supports
debver('squeeze') < debver($ho->{Suite}) <= debver('wheezy')
like some languages do.

> And it's just another form of saying "if ($ho->{Suite} =~ /XXX/)" IMHO.

The difference is you don't need to enumerate all the names. e.g.
"lenny|squeeze|wheezy" becomes "< debver('wheezy')"

> > Thoughts?
> 
> That would be nice but I doubt it would be of much use -- who
> doesn't want the latest version in production... ;-)

People who think it is useful to continue to test Wheezy for some
reason? People who have other constraints preventing them from upgrading
right away? People who want to use a _newer_ version for some reason and
want to make Stretch work while not breaking Wheezy/Jessie for everyone
else.

If it were expensive to support I'd agree, but I don't think it is,
especially if you arrange to never need to touch it again...

BTW, at some point I'm hoping to extend my distros flight stuff to cover
testing the distro host packages, at which point it would naturally be
useful to cover at least current stable and current testing, if not
oldstable or sid.

Ian.


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

[Xen-devel] "swiotlb buffer is full" problem with tg3 and kernel 3.16.0-4-686-pae on Xen 4.4.1

[Marco Steinacher]

Hi,

After upgrading to Debian jessie, and consequently to the default Linux
kernel 3.16.0-4-686-pae and Xen hypervisor 4.4.1-amd64 in that
distribution, I'm having problems with the tg3 network driver under high
load.  Unfortunately this affects a production system that I am
administrating.  It usually happens when doing a DRBD sync.  Here is one
such event:

[ 4765.528635] block drbd0: Began resync as SyncSource (will sync 886784
KB [221696 bits set])
[ 4765.528654] block drbd0: updated sync UUID
09891C136111799E:F7FD1C0A50225596:F7FC1C0A50225596:F7FB1C0A50225596
[ 4768.992280] tg3 :02:00.0: swiotlb buffer is full (sz: 1448 bytes)
[ 4769.400296] tg3 :02:00.0: swiotlb buffer is full (sz: 1448 bytes)
[ 4770.216360] tg3 :02:00.0: swiotlb buffer is full (sz: 1448 bytes)
[ 4771.852283] tg3 :02:00.0: swiotlb buffer is full (sz: 1448 bytes)
[ 4775.120286] tg3 :02:00.0: swiotlb buffer is full (sz: 1448 bytes)
[ 4775.776027] tg3 :02:00.0: swiotlb buffer is full (sz: 32768 bytes)
[ 4775.778814] tg3 :02:00.0: swiotlb buffer is full (sz: 1448 bytes)
[ 4775.780995] tg3 :02:00.0: swiotlb buffer is full (sz: 1448 bytes)
[ 4775.783345] tg3 :02:00.0: swiotlb buffer is full (sz: 1448 bytes)
[ 4775.785097] tg3 :02:00.0: swiotlb buffer is full (sz: 1448 bytes)
[ 4775.988290] tg3 :02:00.0: swiotlb buffer is full (sz: 1448 bytes)
[ 4776.396285] tg3 :02:00.0: swiotlb buffer is full (sz: 1448 bytes)
[ 4777.212295] tg3 :02:00.0: swiotlb buffer is full (sz: 1448 bytes)
[ 4778.848298] tg3 :02:00.0: swiotlb buffer is full (sz: 1448 bytes)
[ 4781.664292] tg3 :02:00.0: swiotlb buffer is full (sz: 1448 bytes)
[ 4782.120285] tg3 :02:00.0: swiotlb buffer is full (sz: 1448 bytes)
[ 4788.672288] tg3 :02:00.0: swiotlb buffer is full (sz: 1448 bytes)
[ 4793.776046] drbd base-disk: [drbd_w_base-dis/1734] sock_sendmsg time
expired, ko = 6
[ 4794.752314] tg3 :02:00.0: swiotlb buffer is full (sz: 1448 bytes)
[ 4799.776046] drbd base-disk: [drbd_w_base-dis/1734] sock_sendmsg time
expired, ko = 5
[ 4801.760290] tg3 :02:00.0: swiotlb buffer is full (sz: 1448 bytes)
[ 4805.776040] drbd base-disk: [drbd_w_base-dis/1734] sock_sendmsg time
expired, ko = 4
[ 4811.776040] drbd base-disk: [drbd_w_base-dis/1734] sock_sendmsg time
expired, ko = 3
[ 4817.776050] drbd base-disk: [drbd_w_base-dis/1734] sock_sendmsg time
expired, ko = 2
[ 4823.776079] drbd base-disk: [drbd_w_base-dis/1734] sock_sendmsg time
expired, ko = 1
[ 4827.936300] tg3 :02:00.0: swiotlb buffer is full (sz: 1448 bytes)
[ 4829.776069] drbd base-disk: peer( Secondary -> Unknown ) conn(
SyncSource -> Timeout )
[ 4829.776088] block drbd0: drbd_send_block() failed

Sometimes I also see the message "swiotlb_tbl_map_single: 8 callbacks
suppressed" or similar between the "buffer full" messages.

Sometimes the sync finishes, sometimes it stalls and fails completely.

The problem only occurs when running Linux 3.16.0-4-686-pae under Xen
4.4.1.  It does NOT occur when booting the same kernel without Xen, or
when booting the corresponding amd64 kernel (3.16.0-4-amd64) with or
without Xen.  There was no problem in Debian wheezy before the upgrade
(kernel 3.2.0-4-686-pae and Xen Hypervisor 4.1.3-amd64). The problem
also occurs when only dom0 is running (all domU VMs shut down).

I found the thread "tg3 NIC driver bug in 3.14.x under Xen"
(http://www.spinics.net/lists/netdev/msg324124.html) which looks like a
similar issue, but I don't understand exactly what is going on there and
what I could do to fix or debug it further.

Shall I try to build a 3.16.0-4-686-pae kernel with
"CONFIG_NEED_DMA_MAP_STATE=y"?

Shall I try to set the 'iommu' and/or 'swiotlb' kernel parameters? To
what values?

Any help or hint how to fix or work around this issue is very much
appreciated. Also hints how to debug this further are welcome.

Thanks,
Marco

P.S. Here is some information that might help figuring out what's going on:
---
kepler:~# ethtool -S eth0 | grep -v ': 0$'
NIC statistics:
 rx_octets: 42531865
 rx_ucast_packets: 582596
 rx_mcast_packets: 127
 rx_bcast_packets: 1
 tx_octets: 8692263469
 tx_ucast_packets: 5755264
 tx_mcast_packets: 10
---

---
kepler:~# ethtool -i eth0
driver: tg3
version: 3.137
firmware-version: 5722-v3.09, ASFIPMI v6.03
bus-info: :02:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no
---

---
kepler:~# lspci -vvv -s 02:00.0
02:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5722
Gigabit Ethernet PCI Express
Subsystem: IBM IBM System x3350 (Machine type 4192)
Cont

Re: [Xen-devel] [PATCH v10 3/6] Support for BIOS interrupt handler

[Kevin O'Connor]

On Thu, Apr 30, 2015 at 11:34:20AM -0400, Stefan Berger wrote:
> On 04/30/2015 09:21 AM, Xu, Quan wrote:
> >
> >Stefan,
> > Sorry to reply so late to you. I try to make it compatible with Xen 
> > vTPM by below patch
> >Against your serious of 
> >patch(https://github.com/KevinOConnor/seabios/tree/tcg-testing ).
> >Also I have tested this patch, which is working.
[...]
> 
> Kevin, I think this should be good to add after 3/6 ?

Thanks - I applied the first three tpm patches along with this patch.

-Kevin

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

Re: [Xen-devel] [PATCH] xl: Support (by ignoring) xl migrate --live

[Ian Campbell]

On Thu, 2015-05-21 at 18:23 +0200, Olaf Hering wrote:
> On Thu, May 21, Ian Campbell wrote:
> 
> > On Thu, 2015-05-14 at 15:05 +0100, Ian Campbell wrote:
> > > On Thu, 2015-05-14 at 13:41 +0100, Ian Jackson wrote:
> > > > xm migrate would do non-live migration (effectively, save, transfer
> > > > and restore) by default, unless you specified --live.
> > > > 
> > > > xl migrate always does live migration.  Honour (by ignoring) --live
> > > > for compatibility with old callers.  Document this.
> > > > 
> > > > (This patch should be backported as far as possible.)
> > > > 
> > > > Reported-by: Matthew Vernon 
> > > > Signed-off-by: Ian Jackson 
> > > > CC: Matthew Vernon 
> > > 
> > > Acked-by: Ian Campbell 
> > 
> > Applied, thanks.
> 
> I think this causes a build failure, somewhere introduced here:
> 
> git log -p -M --stat e13013d..upstream/staging -- docs/man/
> 
> [  146s] man/xl.pod.1 around line 1529: '=item' outside of any '=over'
> [  146s] man/xl.pod.1 around line 1531: You forgot a '=back' before '=head1'
> [  146s] POD document had syntax errors at /usr/bin/pod2text line 84.
> [  146s] Makefile:167: recipe for target 'txt/man/xl.1.txt' failed
> [  146s] make[1]: *** [txt/man/xl.1.txt] Error 255

My pod2text doesn't seem to complain, but does this help?

-8>---

>From 5da86305c378482ab2f6359375bd1b63ddc51102 Mon Sep 17 00:00:00 2001
From: Ian Campbell 
Date: Thu, 21 May 2015 17:31:39 +0100
Subject: [PATCH] docs: correct pod syntax

Olaf reports:
[  146s] man/xl.pod.1 around line 1529: '=item' outside of any '=over'
[  146s] man/xl.pod.1 around line 1531: You forgot a '=back' before '=head1'
[  146s] POD document had syntax errors at /usr/bin/pod2text line 84.
[  146s] Makefile:167: recipe for target 'txt/man/xl.1.txt' failed
[  146s] make[1]: *** [txt/man/xl.1.txt] Error 255

Reported-by: Olaf Hering 
Signed-off-by: Ian Campbell 
---
 docs/man/xl.pod.1 |4 
 1 file changed, 4 insertions(+)

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index b2bc362..4eb929d 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -1526,8 +1526,12 @@ xl is mostly command-line compatible with the old xm 
utility used with
 the old Python xend.  For compatibility, the following options are
 ignored:
 
+=over 4
+
 =item B
 
+=back
+
 =head1 TO BE DOCUMENTED
 
 We need better documentation for:
-- 
1.7.10.4




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

Re: [Xen-devel] [PATCH OSSTEST 3/5] Cope with Jessie's d-i vg name

[Wei Liu]

On Thu, May 21, 2015 at 04:10:02PM +0100, Ian Campbell wrote:
> On Wed, 2015-05-20 at 18:56 +0100, Wei Liu wrote:
> > In ts-xen-build-prep, replace matching lenny with jessie since lenny is
> > not used in production anymore.
> 
> AIUI the default VG name scheme changed? Can you say how here please.
> 

Sure.

> Also I think in general we should aim for the "non-exceptional" case to
> be the default one, and use explicit matching for issues with historical
> versions. IOW test for wheezy and earlier and override the default (i.e.
> Jessie) name. The rationale is that we shouldn't need to add Stretch
> here too unless it also differs from Jessie.
> 
> That principal seems to apply to a some of the following patches too.
> 
> WRT "wheezy and earlier" I've been wondering about providing a function
> to transform a Debian code name to a sortable integer. e.g.
> 
> sub debver($) {
> my %vers = qw(Lenny 50
>   Squeeze 60
>   Wheezy 70
>   Jessie 80
>   Stretch 90
>   Sid 100);
> # Unknown is > sid...
> return $vers{ucfirst($_[0])) // 101;
> }
> 
> so you can do things like
> if ( debver($ho->{Suite}) < debver('jessie') ) {
> workaround_a_thing();
> 

You would need to test for "$ho->{Suite} == A" or "A < $ho->{Suite} < B".

And it's just another form of saying "if ($ho->{Suite} =~ /XXX/)" IMHO.

> Thoughts?

That would be nice but I doubt it would be of much use -- who
doesn't want the latest version in production... ;-)

Wei.

> Ian.
> 
> > 
> > Signed-off-by: Wei Liu 
> > ---
> >  ts-host-install   | 4 +++-
> >  ts-xen-build-prep | 4 ++--
> >  2 files changed, 5 insertions(+), 3 deletions(-)
> > 
> > diff --git a/ts-host-install b/ts-host-install
> > index b73c7ff..6e2106e 100755
> > --- a/ts-host-install
> > +++ b/ts-host-install
> > @@ -87,7 +87,9 @@ END
> >  
> >  await_tcp(get_timeout($ho,'reboot',$timeout{Sshd}), 14,$ho);
> >  
> > -our $vgname= $ho->{Name};
> > +our $vgname= $ho->{Suite} =~ m/jessie/
> > + ? "$ho->{Name}-vg"
> > + : $ho->{Name};
> >  
> >  if ($ho->{Suite} =~ m/lenny/) {
> >  $vgname .= ".$c{TestHostDomain}";
> > diff --git a/ts-xen-build-prep b/ts-xen-build-prep
> > index 4dece65..25ba3d4 100755
> > --- a/ts-xen-build-prep
> > +++ b/ts-xen-build-prep
> > @@ -53,8 +53,8 @@ sub overall_limit_pe ($) {
> >  
> >  sub determine_vg_lv () {
> >  $vg=
> > -$ho->{Suite} =~ m/lenny/
> > -? "$ho->{Name}.$c{TestHostDomain}"
> > +$ho->{Suite} =~ m/jessie/
> > +? "$ho->{Name}-vg"
> >  : $ho->{Name};
> >  $lv = "/dev/$vg/$lvleaf";
> >  }
> 

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

Re: [Xen-devel] [PING] [PING] [PATCH] tools/libxc: Fix build of 32bit toolstacks on CentOS 5.x following XSA-125

[Andrew Cooper]

This patch is still needed in all branches which currently contain
XSA-125, including staging.

~Andrew

On 13/05/15 12:42, Andrew Cooper wrote:
> Ping again.
>
> These should be included in 4.5.1
>
> ~Andrew
>
> On 22/04/15 16:43, Andrew Cooper wrote:
>> Ping on the patches themselves?
>>
>> On 13/04/15 17:37, Andrew Cooper wrote:
>>> On 13/04/15 17:33, Ian Jackson wrote:
 Andrew Cooper writes ("[Xen-devel] [PATCH] tools/libxc: Fix build of 32bit 
 toolstacks on CentOS 5.x following XSA-125"):
> gcc 4.1 of CentOS 5.x era does not like the typecheck in min() between
> uint64_t and unsigned long.
>
> Signed-off-by: Andrew Cooper 
> CC: Konrad Rzeszutek Wilk 
> CC: Ian Campbell 
> CC: Ian Jackson 
> CC: Wei Liu 
 As and when this is acked and pushed to #staging, we should update the
 advisory.

> This needs backporting to 4.5
 To be clear, do you know whether this is a trivial cherry pick ?
>>> It is trivial to cherrypick.
>>>
>>> 4.4 is the problematic case which I did the backport for separately, but
>>> then that is trivial to cherrypick back to 4.2
>>>
>>> ~Andrew
>>>
>>> ___
>>> Xen-devel mailing list
>>> Xen-devel@lists.xen.org
>>> http://lists.xen.org/xen-devel
>> ___
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


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

Re: [Xen-devel] [PATCH v2] tools: add configure --with-dumpdir=DIR option

[Ian Campbell]

On Thu, 2015-05-21 at 16:27 +0200, Olaf Hering wrote:
> On Thu, May 21, Ian Campbell wrote:
> 
> > On Mon, 2015-05-11 at 15:33 +, Olaf Hering wrote:
> > [...]
> > > +AC_ARG_WITH([xen-dumpdir],
> > > +AS_HELP_STRING([--with-xen-dumpdir=DIR],
> > > +[Path to directory for domU crash dumps. [/var/lib/xen/dump]]),
> > 
> > Should this say $localstatedir/lib/xen/dump as below?
> 
> This is the help output, the line below is a variable assignment.
> I think its ok as it is. Perhaps /var can be replaced with LOCALSTATEDIR
> to make it clearer.

Based on the other things in configure --help I think that's right. Ive
applied making that change, thanks.

> configure --help suggests that --localestatedir is PREFIX/var, but we
> force it to be /var. Too bad that can not be changed because it comes
> from generic code, I think.

I vaguely recall coming to the same conclusion when I looked at this :-(



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

Re: [Xen-devel] [PATCH] xl: Support (by ignoring) xl migrate --live

[Olaf Hering]

On Thu, May 21, Ian Campbell wrote:

> On Thu, 2015-05-14 at 15:05 +0100, Ian Campbell wrote:
> > On Thu, 2015-05-14 at 13:41 +0100, Ian Jackson wrote:
> > > xm migrate would do non-live migration (effectively, save, transfer
> > > and restore) by default, unless you specified --live.
> > > 
> > > xl migrate always does live migration.  Honour (by ignoring) --live
> > > for compatibility with old callers.  Document this.
> > > 
> > > (This patch should be backported as far as possible.)
> > > 
> > > Reported-by: Matthew Vernon 
> > > Signed-off-by: Ian Jackson 
> > > CC: Matthew Vernon 
> > 
> > Acked-by: Ian Campbell 
> 
> Applied, thanks.

I think this causes a build failure, somewhere introduced here:

git log -p -M --stat e13013d..upstream/staging -- docs/man/

[  146s] man/xl.pod.1 around line 1529: '=item' outside of any '=over'
[  146s] man/xl.pod.1 around line 1531: You forgot a '=back' before '=head1'
[  146s] POD document had syntax errors at /usr/bin/pod2text line 84.
[  146s] Makefile:167: recipe for target 'txt/man/xl.1.txt' failed
[  146s] make[1]: *** [txt/man/xl.1.txt] Error 255

Olaf

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

Re: [Xen-devel] [PATCH] xen: Move preinit_xen_time in ARM headers

[Ian Campbell]

On Thu, 2015-05-21 at 15:31 +0100, Julien Grall wrote:
> This function is ARM specific. It's has been added by mistake in the
> common code.
> 
> Signed-off-by: Julien Grall 

Acked + applied, thanks.



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

Re: [Xen-devel] [linux-next test] 56810: regressions - FAIL

[Ian Campbell]

On Thu, 2015-05-21 at 15:58 +0200, Roger Pau Monné wrote:
> El 21/05/15 a les 4.40, osstest service user ha escrit:
> > flight 56810 linux-next real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/56810/
> > 
> > Regressions :-(
> > 
> > Tests which did not succeed and are blocking,
> > including tests which could not be run:
> >  test-amd64-i386-rumpuserxen-i386 15 
> > rumpuserxen-demo-xenstorels/xenstorels.repeat fail REGR. vs. 56718
> > 
> > Regressions which are regarded as allowable (not blocking):
> >  test-armhf-armhf-libvirt 11 guest-start   fail REGR. vs. 
> > 56718
> >  test-amd64-i386-freebsd10-i386  9 freebsd-install  fail like 
> > 56718
> >  test-amd64-i386-freebsd10-amd64  9 freebsd-install fail like 
> > 56718

> Is there any chance we could bisect this before it makes its way into
> stable kernels?

linux-next isn't fast forwarding so I expect the automatic bisector
won't even try.

I was going to suggest that it may be possible to use a recent
linux-linus result as a baseline for an ad-hoc bisection, by finding one
with a pass on a revision which was an ancestor of 0ebc274769c (that is
the linux-next revision under test here).

But when I went to look I found that this is is already also failing in
linux-linus, and seems to have been for as long as these urls go back to
(which extends to the old Cambridge instance too):

http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-i386-freebsd10-amd64.linux-next.html
http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-i386-freebsd10-amd64.linux-linus.html

In fact it seems to have already been broken in

http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-i386-freebsd10-amd64.linux-3.16.html

The first set of successful tests appear in

http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-i386-freebsd10-amd64.linux-3.14.html

Figuring this out will probably involve a few adhoc test runs to
establish some baselines and then taking it from there.

Ian.


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

Re: [Xen-devel] [PATCHv9 3/4] gnttab: make the grant table lock a read-write lock

[David Vrabel]

On 21/05/15 15:53, Jan Beulich wrote:
 On 21.05.15 at 15:36,  wrote:
>> On 21/05/15 11:32, Jan Beulich wrote:
>> On 20.05.15 at 17:54,  wrote:
 @@ -827,9 +828,11 @@ __gnttab_map_grant_ref(
  if ( (wrc + rdc) == 0 )
  err = iommu_map_page(ld, frame, frame, IOMMUF_readable);
  }
 +
 +double_gt_lock(lgt, rgt);
>>>
>>> unlock. And with this code path actually used (due to the bug it's
>>> pretty clear it didn't get exercised in your testing), how does
>>> performance look like? 
>>
>> I think it will be no worse than what it was before -- this path already
>> really sucks (mapcount() loops over 1000s of entries).  I don't care
>> about this path at all.
> 
> It's kind of strange that you don't care about this case - afaict we're
> not getting there by default solely because dom0-strict mode is not
> currently the default (albeit arguably it should be).

What's your point?  Are you going to refuse this series unless it also
optimizes dom0-strict mode?

David

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

Re: [Xen-devel] [PATCH] x86/pvh: disable posted interrupts

[Jan Beulich]

>>> On 21.05.15 at 14:14,  wrote:
> --- a/xen/arch/x86/hvm/vmx/vmcs.c
> +++ b/xen/arch/x86/hvm/vmx/vmcs.c
> @@ -980,6 +980,10 @@ static int construct_vmcs(struct vcpu *v)
>  v->arch.hvm_vmx.secondary_exec_control &=
>  ~SECONDARY_EXEC_UNRESTRICTED_GUEST;
>  
> +/* Disable posted interrupts */
> +__vmwrite(PIN_BASED_VM_EXEC_CONTROL,
> +vmx_pin_based_exec_control & ~PIN_BASED_POSTED_INTERRUPT);

To be understandable in a few months/years, this should be moved
up a few lines, and the comment should be something like "In turn,
disable posted interrupts." (Please also note the stop at its end.)

Jan


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

Re: [Xen-devel] [PATCH OSSTEST 3/5] Cope with Jessie's d-i vg name

[Ian Campbell]

On Wed, 2015-05-20 at 18:56 +0100, Wei Liu wrote:
> In ts-xen-build-prep, replace matching lenny with jessie since lenny is
> not used in production anymore.

AIUI the default VG name scheme changed? Can you say how here please.

Also I think in general we should aim for the "non-exceptional" case to
be the default one, and use explicit matching for issues with historical
versions. IOW test for wheezy and earlier and override the default (i.e.
Jessie) name. The rationale is that we shouldn't need to add Stretch
here too unless it also differs from Jessie.

That principal seems to apply to a some of the following patches too.

WRT "wheezy and earlier" I've been wondering about providing a function
to transform a Debian code name to a sortable integer. e.g.

sub debver($) {
my %vers = qw(Lenny 50
  Squeeze 60
  Wheezy 70
  Jessie 80
  Stretch 90
  Sid 100);
# Unknown is > sid...
return $vers{ucfirst($_[0])) // 101;
}

so you can do things like
if ( debver($ho->{Suite}) < debver('jessie') ) {
workaround_a_thing();

Thoughts?
Ian.

> 
> Signed-off-by: Wei Liu 
> ---
>  ts-host-install   | 4 +++-
>  ts-xen-build-prep | 4 ++--
>  2 files changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/ts-host-install b/ts-host-install
> index b73c7ff..6e2106e 100755
> --- a/ts-host-install
> +++ b/ts-host-install
> @@ -87,7 +87,9 @@ END
>  
>  await_tcp(get_timeout($ho,'reboot',$timeout{Sshd}), 14,$ho);
>  
> -our $vgname= $ho->{Name};
> +our $vgname= $ho->{Suite} =~ m/jessie/
> + ? "$ho->{Name}-vg"
> + : $ho->{Name};
>  
>  if ($ho->{Suite} =~ m/lenny/) {
>  $vgname .= ".$c{TestHostDomain}";
> diff --git a/ts-xen-build-prep b/ts-xen-build-prep
> index 4dece65..25ba3d4 100755
> --- a/ts-xen-build-prep
> +++ b/ts-xen-build-prep
> @@ -53,8 +53,8 @@ sub overall_limit_pe ($) {
>  
>  sub determine_vg_lv () {
>  $vg=
> -$ho->{Suite} =~ m/lenny/
> -? "$ho->{Name}.$c{TestHostDomain}"
> +$ho->{Suite} =~ m/jessie/
> +? "$ho->{Name}-vg"
>  : $ho->{Name};
>  $lv = "/dev/$vg/$lvleaf";
>  }



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

Re: [Xen-devel] [PATCH] docs: remove qemu-upstream_howto_use_it.markdown

[Ian Campbell]

On Thu, 2015-05-21 at 16:03 +0100, Wei Liu wrote:
> On Thu, May 21, 2015 at 03:54:01PM +0100, Ian Campbell wrote:
> > On Mon, 2015-05-18 at 17:37 +0100, Wei Liu wrote:
> > > QEMU upstream has been the default for several releases. The only
> > > setting described in that document is no longer required.
> > > 
> > > Signed-off-by: Wei Liu 
> > > Cc: Ian Campbell 
> > > Cc: Ian Jackson 
> > > Cc: Jan Beulich 
> > > Cc: Keir Fraser 
> > > Cc: Tim Deegan 
> > > Cc: Anthony Perard 
> > 
> > Acked + applied, thanks.
> > 
> > Is http://wiki.xenproject.org/wiki/QEMU_Upstream up to date / useful?
> > 
> 
> That page looks fine to me. Most if not all information is accurate.

That's about as good as a wiki ever gets ;-)

Thanks.

Ian.



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

Re: [Xen-devel] [PATCH] docs: remove qemu-upstream_howto_use_it.markdown

[Wei Liu]

On Thu, May 21, 2015 at 03:54:01PM +0100, Ian Campbell wrote:
> On Mon, 2015-05-18 at 17:37 +0100, Wei Liu wrote:
> > QEMU upstream has been the default for several releases. The only
> > setting described in that document is no longer required.
> > 
> > Signed-off-by: Wei Liu 
> > Cc: Ian Campbell 
> > Cc: Ian Jackson 
> > Cc: Jan Beulich 
> > Cc: Keir Fraser 
> > Cc: Tim Deegan 
> > Cc: Anthony Perard 
> 
> Acked + applied, thanks.
> 
> Is http://wiki.xenproject.org/wiki/QEMU_Upstream up to date / useful?
> 

That page looks fine to me. Most if not all information is accurate.

> Ian.

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

Re: [Xen-devel] [PATCH OSSTEST 1/5] mg-debian-installer-update: use new url for armhf packages

[Ian Campbell]

On Wed, 2015-05-20 at 18:56 +0100, Wei Liu wrote:
> When we use Wheezy the arm kernel is only available in wheezy-backports.
> In Jessie it is not in backports.
> 
> Signed-off-by: Wei Liu 
> ---
> Not sure if this patch does the right thing.

I have some patches addressing this in a more flexible way in my local
branch where I am working on arm64 support, which overlaps a bit with
"make Jessie work" since arm64 only arrived with Jessie

I'm hoping to post an RFC of that stuff shortly...




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

Re: [Xen-devel] Plans for the SEDF scheduler

[Ian Campbell]

On Thu, 2015-05-21 at 13:45 +0100, George Dunlap wrote:
[...]
> >  2. keep the field 'physically', but return warnings and errors when it 
> > is used. This is a change in behavior, so also not really stable
> > (but, hey, the scheduler is going away, the behavior will change,
> > one way or another!)
> 
> I think this is probably the best option.

Agreed.

[...]
> I think given that it's been "going away" for 9 years, we should
> probably just remove it

Agreed.

>  and put it back if people complain.  (And if
> they really really can't use RTDS instead.)

Nah ;-)

Ian.


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

Re: [Xen-devel] [PATCH] docs: remove qemu-upstream_howto_use_it.markdown

[Ian Campbell]

On Mon, 2015-05-18 at 17:37 +0100, Wei Liu wrote:
> QEMU upstream has been the default for several releases. The only
> setting described in that document is no longer required.
> 
> Signed-off-by: Wei Liu 
> Cc: Ian Campbell 
> Cc: Ian Jackson 
> Cc: Jan Beulich 
> Cc: Keir Fraser 
> Cc: Tim Deegan 
> Cc: Anthony Perard 

Acked + applied, thanks.

Is http://wiki.xenproject.org/wiki/QEMU_Upstream up to date / useful?

Ian.


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

Re: [Xen-devel] [PATCH] xen/arm: Drop support of platform where GICH_LR_HW is not working correctly

[Ian Campbell]

On Mon, 2015-05-18 at 21:55 +0530, Pranavkumar Sawargaonkar wrote:
> [...]

> Thanks for this patch.
> Acked-by: Pranavkumar Sawargaonkar 

Acked + Applied, thanks.



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

Re: [Xen-devel] [PATCH] libxl: fix "xl mem-set" regression from 0c029c4da2

[Ian Campbell]

On Wed, 2015-05-13 at 14:46 +0100, Ian Campbell wrote:
> > So what's the situation with this patch? Can it go in? Is someone
> > working on a better fix for the described problem?
> 
> Stefano, Are you?
> 
> Regardless it seems to me that this patch is correct in its own right,
> having maxmem_kb be a 64-bit type is the correct type for it to have.

No one objected so I've now applied.

Ian.


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

Re: [Xen-devel] [PATCH v3 6/6] libxl: assign a default ssidref (XSM label) to guests

[Ian Campbell]

On Wed, 2015-05-20 at 10:51 -0400, Daniel De Graaf wrote:
> On 05/20/2015 10:39 AM, Ian Campbell wrote:
> > We have now arranged for SECINITSID_DOMU and SECINITSID_DOMDM to be
> > defined (correspondng to system_u:system_r:domU_t and
> > system_u:system_r:dm_dom_t respectively in the default policy). Use
> > these as the default for the SSID of every (stub)domain.
> >
> > Signed-off-by: Ian Campbell 
> 
> Acked-by: Daniel De Graaf 

Thanks, all applied with Wei and your acks.

Ian.


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

Re: [Xen-devel] [PATCH] tools/configure: Missing [ in the aio check

[Ian Campbell]

On Wed, 2015-05-20 at 14:02 +0100, Julien Grall wrote:
> There was a missing [ in the aio check which lead to never check if aio
> is present on the platform.
> 
> Signed-off-by: Julien Grall 

Acked + Applied, thanks.



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

Re: [Xen-devel] [PATCH] tools: Fix wild memory allocations from c/s 250f0b4 and 85d78b4

[Ian Campbell]

On Mon, 2015-05-18 at 14:03 +0100, Wei Liu wrote:
> On Mon, May 18, 2015 at 01:57:24PM +0100, Andrew Cooper wrote:
> > These changesets cause the respective libxc functions to unconditonally
> > dereference their max_cpus/nodes parameters as part of initial memory
> > allocations.  It will fail at obtaining the correct number of cpus/nodes 
> > from
> > Xen, as the guest handles will not be NULL.
> > 
> > Signed-off-by: Andrew Cooper 
> > CC: Ian Campbell 
> > CC: Ian Jackson 
> > CC: Wei Liu 
> > CC: Boris Ostrovsky 
> > 
> 
> Acked-by: Wei Liu 

Applied, thanks.



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

Re: [Xen-devel] [PATCH] MAINTAINERS: Remove Frediano Ziglio from "HISILICON HIP04 Support"

[Ian Campbell]

On Mon, 2015-05-18 at 10:37 +0100, Ian Campbell wrote:
> Unless someone objects I'm going to pick this up next time I do a pass
> over my queue committing things, which will likely be either later today
> or tomorrow.

Done.

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



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

Re: [Xen-devel] [PATCH] libxl: 'valid_devs' may be used uninitialized

[Ian Campbell]

On Fri, 2015-05-15 at 19:39 +0200, Dario Faggioli wrote:
> On Fri, 2015-05-15 at 11:06 -0600, Charles Arnold wrote:
> > Using gcc 4.8 to compile with -Werror.
> > 
> > xl_cmdimpl.c:5493:8: error: 'valid_devs' may be used uninitialized in this 
> > function [-Werror=maybe-uninitialized]
> >   if (valid_devs == 0)
> >  ^
> > xl_cmdimpl.c:5455:9: note: 'valid_devs' was declared here
> >   int valid_devs;
> > 
> > Signed-off-by: Charles Arnold 
> > 
> Reviewed-by: Dario Faggioli 

Acked + applied, thanks



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

Re: [Xen-devel] [PATCH] xen/arm: gic: Typo in comment in gic_remove_irq_from_guest

[Ian Campbell]

On Fri, 2015-05-15 at 16:17 +0100, Julien Grall wrote:
> Signed-off-by: Julien Grall 

Acked + applied, thanks.



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

Re: [Xen-devel] [PATCH] libxl: Initialize valid_devs in output_topologyinfo()

[Ian Campbell]

On Mon, 2015-05-18 at 10:48 +0100, Wei Liu wrote:
> On Fri, May 15, 2015 at 11:06:57AM -0400, Boris Ostrovsky wrote:
> > Commit e78e8b9bb649 ("libxl: Add interface for querying hypervisor
> > about PCI topology") neglected to initialize valid_devs. This
> > may result in not printing a message to console if no IO topology
> > information is available and, more importantly, may break non-debug
> > builds on some versions of gcc.
> > 
> > Signed-off-by: Boris Ostrovsky 
> > Reported-by: Olaf Hering 
> 
> Acked-by: Wei Liu 

Thanks, but I already just applied a similar looking patch from Charles
Arnold.

> 
> > ---
> >  tools/libxl/xl_cmdimpl.c |2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> > 
> > diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> > index 373aa37..6d60ce4 100644
> > --- a/tools/libxl/xl_cmdimpl.c
> > +++ b/tools/libxl/xl_cmdimpl.c
> > @@ -5423,7 +5423,7 @@ static void output_topologyinfo(void)
> >  libxl_cputopology *cpuinfo;
> >  int i, nr;
> >  libxl_pcitopology *pciinfo;
> > -int valid_devs;
> > +int valid_devs = 0;
> >  
> >  
> >  cpuinfo = libxl_get_cpu_topology(ctx, &nr);
> > -- 
> > 1.7.1



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

Re: [Xen-devel] [PATCH] docs: fix typo in xl.cfg:vfb=

[Ian Campbell]

On Fri, 2015-05-15 at 06:23 +, Olaf Hering wrote:
> Use singular for option, it refers to vfb= itself.
> 
> Signed-off-by: Olaf Hering 
> Cc: Ian Campbell 
> Cc: Ian Jackson 

Acked + applied, thanks.



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

Re: [Xen-devel] [PATCH] xl: Support (by ignoring) xl migrate --live

[Ian Campbell]

On Thu, 2015-05-14 at 15:05 +0100, Ian Campbell wrote:
> On Thu, 2015-05-14 at 13:41 +0100, Ian Jackson wrote:
> > xm migrate would do non-live migration (effectively, save, transfer
> > and restore) by default, unless you specified --live.
> > 
> > xl migrate always does live migration.  Honour (by ignoring) --live
> > for compatibility with old callers.  Document this.
> > 
> > (This patch should be backported as far as possible.)
> > 
> > Reported-by: Matthew Vernon 
> > Signed-off-by: Ian Jackson 
> > CC: Matthew Vernon 
> 
> Acked-by: Ian Campbell 

Applied, thanks.

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



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

Re: [Xen-devel] [PATCH v2 0/7] tools: remove private Makefile variables

[Ian Campbell]

On Mon, 2015-05-11 at 15:24 +, Olaf Hering wrote:
> Replace all private variables in Makefiles with automake variables.
> This series is based on f48218fd2d35e274ef58caee889aecd6610c8cb6.

Applied, thanks.



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

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

[osstest service user]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt 11 guest-start   fail REGR. vs. 53854
 test-amd64-i386-libvirt  11 guest-start   fail REGR. vs. 53854
 build-armhf-libvirt   5 libvirt-build fail REGR. vs. 53854

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt-xsm 11 guest-start  fail   never pass

version targeted for testing:
 libvirt  bc89ebe564e80387d4f6a766e0c0869a981e2fa7
baseline version:
 libvirt  fd74e231751334b64af0934b680c5cc62f652453


People who touched revisions under test:
  Andrea Bolognani 
  Boris Fiuczynski 
  Cole Robinson 
  Daniel Hansel 
  Jim Fehlig 
  Jiri Denemark 
  John Ferlan 
  Ján Tomko 
  Laine Stump 
  Luyao Huang 
  Martin Kletzander 
  Michal Privoznik 
  Nikolay Shirokovskiy 
  Pavel Hrdina 
  Peter Krempa 
  Richard W.M. Jones 
  Roman Bogorodskiy 
  Tony Krowiak 
  Tony Krowiak 
  Viktor Mihajlovski 
  Wang Yufei 
  Zhang Bo 


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  fail
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-xsm fail
 test-armhf-armhf-libvirt-xsm blocked
 test-amd64-i386-libvirt-xsm  fail
 test-amd64-amd64-libvirt fail
 test-armhf-armhf-libvirt blocked
 test-amd64-i386-libvirt  fail



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

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

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


Not pushing.

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

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

Re: [Xen-devel] [PATCH] xen/arm: gic-v3: Implement correctly the callback send_SGI

[Ian Campbell]

On Sat, 2015-05-09 at 21:13 +0800, Chen Baozi wrote:
> On Fri, May 08, 2015 at 06:01:12PM +0100, Julien Grall wrote:
> > Currently, the GICv3 driver is only able to send an SGI when the cpumask
> > is provided. Although with the modes SGI_TARGET_OTHERS and SGI_TARGET_SELF,
> > no cpumask is provided. Any usage of those modes will crash the hypersivor.
> > 
> > Rename gicv3_send_sgi to gicv3_send_sgi_list and implement the
> > different modes:
> > - SGI_TARGET_OTHERS: Set the Interrupt Routing Mode (bit 40) to 1
> > (see Table 4 on Section 4.2.6 PRD03-GENC-010745 24.0)
> > - SGI_TARGET_SELF: Unlike GICv2, the GICv3 SGI registers don't
> > provide a specific field. So use gicv3_send_sgi_list and pass
> > the cpumask of the current CPU
> > - SGI_TARGET_LIST: Directly call gicv3_send_sgi_list with the given
> > cpumask
> > 
> > Also, use WRITE_SYSREG64 to write into ICC_SGI1R_EL1 the access is
> > 64-bit on all the architectures.
> > 
> > Reported-by: Chen Baozi 
> > Signed-off-by: Julien Grall 
> Tested-by: Chen Baozi 

Acked + applied, thanks.



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

Re: [Xen-devel] [PATCH 0/2] tools: enable sdl display and xauth

[Ian Campbell]

On Mon, 2015-04-20 at 13:40 +, Olaf Hering wrote:
> For some reason DISPLAY and XAUTHORITY are not set by libxl. 
> Thats not an issue for xl(1) because it can reuse the DISPLAY from the
> calling process. But libvirtd will benefit from being able to pass the
> configured display and xauth settings.

Applied. Sorry for the delay.



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

Re: [Xen-devel] [PATCH v9 0/6] xen/arm: Add support for non-PCI passthrough

[Ian Campbell]

On Wed, 2015-05-13 at 19:33 +0100, Julien Grall wrote:
> Hi all,
> 
> This is a resend of the last part of the non-PCI passthrough after another
> error found by Ian C. during build compilation on Debian Wheezy.

Applied, with the replacement patch #1. Thanks.

Ian.


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

Re: [Xen-devel] [PATCH] tools/libx: Don't export libxl__arch_* to the library

[Ian Campbell]

On Wed, 2015-05-20 at 14:01 +0100, Julien Grall wrote:
> From: Julien Grall 
> 
> libxl__arch_* should only be used internally by libxl.
> 
> Signed-off-by: Julien Grall 

Acked + applied, thanks.



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

Re: [Xen-devel] [PATCH v9 1/6] tools/libxl: Check if fdt_{first, next}_subnode are present in libfdt

[Ian Campbell]

On Thu, 2015-05-21 at 15:25 +0100, Julien Grall wrote:
> On 21/05/15 15:13, Ian Campbell wrote:
> > On Wed, 2015-05-20 at 13:59 +0100, Julien Grall wrote:
> >> [...]
> >> From d4f0ea84f26649b61bc6afb550348069b71d41c5 Mon Sep 17 00:00:00 2001
> >> From: Julien Grall 
> >> Date: Tue, 17 Mar 2015 17:58:14 +
> >> Subject: [PATCH] tools/libxl: Check if fdt_{first,next}_subnode are 
> >> present in
> >>  libfdt
> >>
> >> The functions fdt_{first,next}_subnode may not be available because:
> >> * It has been introduced in 2013 => Doesn't work on Wheezy
> >> * The prototype exists but the functions are not exposed. Don't ask
> >> why...
> >>
> >> The later has been fixed recently in the dtc repo [1]
> > 
> > But the bug is still present in 1.4.0, right? Hence this patch is not
> > obsolete even given the next one.
> 
> It is present until 1.4.1. The changes will be on the next released of
> libfdt.
> 
> The commit may be useful for people building there own libfdt.

Right, I shall carry on with committing both then, thanks.


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

Re: [Xen-devel] [PATCH v6 2/2] kconfig: add xenconfig defconfig helper

[Masahiro Yamada]

Hi,

I am not familiar with xen at all, just some comments
from the build system side.



2015-05-21 3:53 GMT+09:00 Luis R. Rodriguez :
> From: "Luis R. Rodriguez" 
>
> This lets you build a kernel which can support xen dom0
> or xen guests on i386, x86-64 and arm64 by just using:
>
>make xenconfig
>
> You can start from an allnoconfig and then switch to xenconfig.
> This also splits out the options which are available currently
> to be built with x86 and 'make ARCH=arm64' under a shared config.
>
> Technically xen supports a dom0 kernel and also a guest
> kernel configuration but upon review with the xen team
> since we don't have many dom0 options its best to just
> combine these two into one.
>
> A few generic notes: we enable both of these:
>
> CONFIG_INET=y
> CONFIG_BINFMT_ELF=y
>
> although technically not required given you likely will
> end up with a pretty useless system otherwise.
>
> A few architectural differences worth noting:
>
> $ make allnoconfig; make xenconfig > /dev/null ; \
> grep XEN .config > 64-bit-config
> $ make ARCH=i386 allnoconfig; make ARCH=i386 xenconfig > /dev/null; \
> grep XEN .config > 32-bit-config
> $ make ARCH=arm64 allnoconfig; make ARCH=arm64 xenconfig > /dev/null; \
> grep XEN .config > arm64-config
>
> Since the options are already split up with a generic config and
> architecture specific configs you anything on the x86 configs
> are known to only work right now on x86. For instance arm64 doesn't
> support MEMORY_HOTPLUG yet as such although we try to enabe it
> generically arm64 doesn't have it yet, so we leave the xen
> specific kconfig option XEN_BALLOON_MEMORY_HOTPLUG on x86's config
> file to set expecations correctly.
>
> Then on x86 we have differences between i386 and x86-64. The difference
> between 64-bit-config and 32-bit-config is you don't get XEN_MCE_LOG as
> this is only supported on 64-bit. You also do not get on i386
> XEN_BALLOON_MEMORY_HOTPLUG, there does not seem to be any technical
> reasons to not allow this but I gave up after a few attempts.
>
> Cc: Josh Triplett 
> Cc: Borislav Petkov 
> Cc: Pekka Enberg 
> Cc: David Rientjes 
> Cc: Michal Marek 
> Cc: Randy Dunlap 
> Cc: penb...@kernel.org
> Cc: levinsasha...@gmail.com
> Cc: mtosa...@redhat.com
> Cc: fengguang...@intel.com
> Cc: David Vrabel 
> Cc: Ian Campbell 
> Cc: Konrad Rzeszutek Wilk 
> Cc: xen-de...@lists.xenproject.org
> Acked-by: Stefano Stabellini 
> Acked-by: Julien Grall 
> Acked-by: Michal Marek 
> Acked-by: David Rientjes 
> Reviewed-by: Josh Triplett 
> Signed-off-by: Luis R. Rodriguez 
> ---

> diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
> index 6950032..f52abae 100644
> --- a/scripts/kconfig/Makefile
> +++ b/scripts/kconfig/Makefile
> @@ -115,6 +115,10 @@ PHONY += kvmconfig
>  kvmconfig: kvm_guest.config
> @:
>
> +PHONY += xenconfig
> +xenconfig: xen.config
> +   @:
> +
>  PHONY += tinyconfig
>  tinyconfig:
> $(Q)$(MAKE) -f $(srctree)/Makefile allnoconfig tiny.config


"make xenconfig" is equivalent to "make xen.config"
and only saves one character.

Now we have only three targets for mergeconfig (tiny, kvm, xen),
so it is OK to add this as an alias.
But if we have more such targets, we might have
to consider to use generic targets (*.config) at some point.

I do not intend to block this.
Just take my comment with a grain of salt..


> @@ -140,6 +144,7 @@ help:
> @echo  '  listnewconfig   - List new options'
> @echo  '  olddefconfig- Same as silentoldconfig but sets new 
> symbols to their default value'
> @echo  '  kvmconfig   - Enable additional options for kvm guest 
> kernel support'
> +   @echo  '  xenconfig   - Enable additional options for xen dom0 
> and guest kernel support'
> @echo  '  tinyconfig  - Configure the tiniest possible kernel'
>
>  # lxdialog stuff


If kvmconfig and xenconfig are only available for x86,
is it better to enclose those helps with
ifeq ($(ARCH),x86)
 ...
endif

??


-- 
Best Regards
Masahiro Yamada

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

Re: [Xen-devel] [PATCHv9 3/4] gnttab: make the grant table lock a read-write lock

[Jan Beulich]

>>> On 21.05.15 at 15:36,  wrote:
> On 21/05/15 11:32, Jan Beulich wrote:
> On 20.05.15 at 17:54,  wrote:
>>> @@ -827,9 +828,11 @@ __gnttab_map_grant_ref(
>>>  if ( (wrc + rdc) == 0 )
>>>  err = iommu_map_page(ld, frame, frame, IOMMUF_readable);
>>>  }
>>> +
>>> +double_gt_lock(lgt, rgt);
>> 
>> unlock. And with this code path actually used (due to the bug it's
>> pretty clear it didn't get exercised in your testing), how does
>> performance look like? 
> 
> I think it will be no worse than what it was before -- this path already
> really sucks (mapcount() loops over 1000s of entries).  I don't care
> about this path at all.

It's kind of strange that you don't care about this case - afaict we're
not getting there by default solely because dom0-strict mode is not
currently the default (albeit arguably it should be).

Jan


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

Re: [Xen-devel] [PATCH v9 1/6] tools/libxl: Check if fdt_{first, next}_subnode are present in libfdt

[Julien Grall]

On 21/05/15 15:13, Ian Campbell wrote:
> On Wed, 2015-05-20 at 13:59 +0100, Julien Grall wrote:
>> [...]
>> From d4f0ea84f26649b61bc6afb550348069b71d41c5 Mon Sep 17 00:00:00 2001
>> From: Julien Grall 
>> Date: Tue, 17 Mar 2015 17:58:14 +
>> Subject: [PATCH] tools/libxl: Check if fdt_{first,next}_subnode are present 
>> in
>>  libfdt
>>
>> The functions fdt_{first,next}_subnode may not be available because:
>> * It has been introduced in 2013 => Doesn't work on Wheezy
>> * The prototype exists but the functions are not exposed. Don't ask
>> why...
>>
>> The later has been fixed recently in the dtc repo [1]
> 
> But the bug is still present in 1.4.0, right? Hence this patch is not
> obsolete even given the next one.

It is present until 1.4.1. The changes will be on the next released of
libfdt.

The commit may be useful for people building there own libfdt.

Regards,

-- 
Julien Grall

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

[Xen-devel] [PATCH] xen: Move preinit_xen_time in ARM headers

[Julien Grall]

This function is ARM specific. It's has been added by mistake in the
common code.

Signed-off-by: Julien Grall 
---
 xen/include/asm-arm/time.h | 2 ++
 xen/include/xen/time.h | 1 -
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/xen/include/asm-arm/time.h b/xen/include/asm-arm/time.h
index d544b5b..039039a 100644
--- a/xen/include/asm-arm/time.h
+++ b/xen/include/asm-arm/time.h
@@ -31,6 +31,8 @@ extern void __cpuinit init_timer_interrupt(void);
 /* Counter value at boot time */
 extern uint64_t boot_count;
 
+void preinit_xen_time(void);
+
 #endif /* __ARM_TIME_H__ */
 /*
  * Local variables:
diff --git a/xen/include/xen/time.h b/xen/include/xen/time.h
index bb19511..da4e8d7 100644
--- a/xen/include/xen/time.h
+++ b/xen/include/xen/time.h
@@ -12,7 +12,6 @@
 #include 
 
 extern int init_xen_time(void);
-void preinit_xen_time(void);
 extern void cstate_restore_tsc(void);
 
 extern unsigned long cpu_khz;
-- 
2.1.4


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

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

[osstest service user]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-freebsd10-amd64 14 guest-saverestore.2fail REGR. vs. 56375
 test-armhf-armhf-xl-credit2  15 guest-start/debian.repeat fail REGR. vs. 56375
 test-armhf-armhf-xl-multivcpu 17 leak-check/check fail REGR. vs. 56375
 test-amd64-i386-xl-qemuu-win7-amd64  9 windows-installfail REGR. vs. 56375

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-libvirt 11 guest-start   fail REGR. vs. 56375
 test-armhf-armhf-libvirt 11 guest-start  fail   like 56375
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 56375
 test-amd64-i386-libvirt  11 guest-start  fail   like 56375

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail never 
pass
 test-amd64-amd64-xl-xsm  11 guest-start  fail   never pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail never 
pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail never 
pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail never 
pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-xl-xsm   11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-libvirt-xsm 11 guest-start  fail   never pass
 test-amd64-i386-libvirt-xsm  11 guest-start  fail   never pass
 test-armhf-armhf-libvirt-xsm 11 guest-start  fail   never pass
 test-armhf-armhf-xl-xsm  11 guest-start  fail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-sedf-pin 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail never pass
 test-armhf-armhf-xl-sedf 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass

version targeted for testing:
 xen  28c0ec1d952ec37209e96310a6ea18ffbe218d98
baseline version:
 xen  e13013dbf1d5997915548a3b5f1c39594d8c1d7b


People who touched revisions under test:
  Andrew Cooper 
  David Vrabel 
  George Dunlap 
  Ian Campbell 
  Jan Beulich 
  Julien Grall  (ARM)
  Konrad Rzeszutek Wilk 
  Len Brown 
  Roger Pau Monné 
  Tiejun Chen 


jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-oldkern  pass
 build-i386-oldkern   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  pass
 build-i386-rumpuserxen   pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsmfail
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm fail
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmfail
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm fail
 test-amd64-amd64-libvirt-xsm fail
 test-armhf-armhf-libvirt-xsm fail
 test-amd64-i386-libvirt-xsm  fail
 test-amd64-amd64-xl-xsm  fail
 test-armhf-armhf-x

[Xen-devel] Xen block driver: Indirect request

[HANNAS YAYA Issa]

Hello
I am working on xen front|backend driver. When I run io operations 
sometime the request type is indirect request sometimes it is
read|write request. I don't know what differnces exists beetween these 
types of operations.

Can some body explain me?

Thanks

HANNAS

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

Re: [Xen-devel] [PATCH v2] tools: add configure --with-dumpdir=DIR option

[Olaf Hering]

On Thu, May 21, Ian Campbell wrote:

> On Mon, 2015-05-11 at 15:33 +, Olaf Hering wrote:
> [...]
> > +AC_ARG_WITH([xen-dumpdir],
> > +AS_HELP_STRING([--with-xen-dumpdir=DIR],
> > +[Path to directory for domU crash dumps. [/var/lib/xen/dump]]),
> 
> Should this say $localstatedir/lib/xen/dump as below?

This is the help output, the line below is a variable assignment.
I think its ok as it is. Perhaps /var can be replaced with LOCALSTATEDIR
to make it clearer.

configure --help suggests that --localestatedir is PREFIX/var, but we
force it to be /var. Too bad that can not be changed because it comes
from generic code, I think.

Olaf

> Other than that:
> Acked-by: Ian Campbell 
> 
> If you say so I can make that tweak as I apply.
> 
> > +[xen_dumpdir_path=$withval],
> > +[xen_dumpdir_path=$localstatedir/lib/xen/dump])
> > +
> >  if test "$libexecdir" = '${exec_prefix}/libexec' ; then
> >  case "$host_os" in
> >   *netbsd*) ;;
> 
> 

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

Re: [Xen-devel] [PATCH v6 05/10] xsm: add XENMEM_soft_reset support

[Daniel De Graaf]

On 05/21/2015 05:49 AM, Vitaly Kuznetsov wrote:

Daniel De Graaf  writes:


On 05/13/2015 05:49 AM, Vitaly Kuznetsov wrote:

Dummy policy just checks that the current domain is privileged,
in flask policy soft_reset is added to create_domain.

Signed-off-by: Vitaly Kuznetsov 


I think the FLASK policy should also check that memory can be moved
from d1 to d2, independent of the check that the toolstack can move
the memory of d1 (or d2).  While I would expect that the security
contexts of d1 and d2 would be identical in most cases (and only
allow that in the example policy), there may be reasons to change
the context along with the kexec operation.  The best examples I
can think of are kexec from a bootloader domain of some kind, or
an installation that transitions into an active system that needs
access to a different network or set of peer domains.

For the example, policy, I'd add something like
allow $2 $2 : mmu reset_transfer;
to the create_domain interface.


Hi Daniel, thank you for your review!

Did I get you right and you suggest we use two new vectors in MMU class
for soft reset: the first one to check that the domain making the
hypercall is allowed to do it and the second one to check that that
memory can be moved from d1 to d2? In that case the FLASK-related part
of the patch would look like that I suppose:

diff --git a/tools/flask/policy/policy/modules/xen/xen.if 
b/tools/flask/policy/policy/modules/xen/xen.if
index 620d151..ab4fe7d 100644
--- a/tools/flask/policy/policy/modules/xen/xen.if
+++ b/tools/flask/policy/policy/modules/xen/xen.if
@@ -54,10 +54,12 @@ define(`create_domain_common', `
psr_cmt_op };
allow $1 $2:security check_context;
allow $1 $2:shadow enable;
-   allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage 
mmuext_op updatemp };
+   allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage
+   mmuext_op updatemp soft_reset };
allow $1 $2:grant setup;
allow $1 $2:hvm { cacheattr getparam hvmctl irqlevel pciroute sethvmc
setparam pcilevel trackdirtyvram nested };
+   allow $2 $2:mmu reset_transfer;
  ')

  # create_domain(priv, target)
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 11b7453..547d55c 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -383,6 +383,21 @@ static int flask_memory_exchange(struct domain *d)
  return current_has_perm(d, SECCLASS_MMU, MMU__EXCHANGE);
  }

+static int flask_memory_soft_reset(struct domain *d1, struct domain *d2)
+{
+int rc;
+
+rc = current_has_perm(d1, SECCLASS_MMU, MMU__SOFT_RESET);
+if (rc)
+return rc;
+
+rc = current_has_perm(d2, SECCLASS_MMU, MMU__SOFT_RESET);
+if (rc)
+return rc;
+
+return domain_has_perm(d1, d2, SECCLASS_MMU, MMU__RESET_TRANSFER);
+}
+
  static int flask_memory_adjust_reservation(struct domain *d1, struct domain 
*d2)
  {
  return domain_has_perm(d1, d2, SECCLASS_MMU, MMU__ADJUST);
@@ -1617,6 +1632,7 @@ static struct xsm_operations flask_ops = {
  .get_pod_target = flask_get_pod_target,
  .set_pod_target = flask_set_pod_target,
  .memory_exchange = flask_memory_exchange,
+.memory_soft_reset = flask_memory_soft_reset,
  .memory_adjust_reservation = flask_memory_adjust_reservation,
  .memory_stat_reservation = flask_memory_stat_reservation,
  .memory_pin_page = flask_memory_pin_page,
diff --git a/xen/xsm/flask/policy/access_vectors 
b/xen/xsm/flask/policy/access_vectors
index ea556df..6872c1a 100644
--- a/xen/xsm/flask/policy/access_vectors
+++ b/xen/xsm/flask/policy/access_vectors
@@ -366,6 +366,13 @@ class mmu
  #  source = domain making the hypercall
  #  target = domain whose pages are being exchanged
  exchange
+# XENMEM_soft_reset:
+#  source = domain making the hypercall
+#  target = domain being reset (source or destination)
+soft_reset
+#  source = source domain being reset
+#  target = destination domain being reset
+reset_transfer
  # Allow a privileged domain to install a map of a page it does not own.  Used
  # for stub domain device models with the PV framebuffer.
  target_hack

[...]


Yes, this is what I was looking for.  When combined with the rest of the patch:

Acked-by: Daniel De Graaf 

--
Daniel De Graaf
National Security Agency

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

Re: [Xen-devel] [PATCHv9 3/4] gnttab: make the grant table lock a read-write lock

[David Vrabel]

On 21/05/15 14:36, David Vrabel wrote:
> On 21/05/15 11:32, Jan Beulich wrote:
> On 20.05.15 at 17:54,  wrote:
>>> @@ -842,8 +845,6 @@ __gnttab_map_grant_ref(
>>>  mt->ref   = op->ref;
>>>  mt->flags = op->flags;
>>>  
>>> -double_gt_unlock(lgt, rgt);
>>
>> Don't the mt-> updates above need some kind of protection?
> 
> It depends:
> 
> If not gnttab_need_iommu_mapping() but we only need a write barrier
> before the mt->flags store.
> 
> If gnttab_need_iommu_mapping() then a lock is required to prevent racing
> with concurrent mapcount() calls.  This is not a path I care about so
> its easiest to just keep the double lock around this.

Like so:

@@ -806,12 +806,13 @@ __gnttab_map_grant_ref(
 goto undo_out;
 }

-double_gt_lock(lgt, rgt);
-
 if ( gnttab_need_iommu_mapping(ld) )
 {
 unsigned int wrc, rdc;
 int err = 0;
+
+double_gt_lock(lgt, rgt);
+
 /* We're not translated, so we know that gmfns and mfns are
the same things, so the IOMMU entry is always 1-to-1. */
 mapcount(lgt, rd, frame, &wrc, &rdc);
@@ -837,12 +838,22 @@ __gnttab_map_grant_ref(

 TRACE_1D(TRC_MEM_PAGE_GRANT_MAP, op->dom);

+/*
+ * All maptrack entry users check mt->flags first before using the
+ * other fields so just ensure the flags field is stored last.
+ *
+ * However, if gnttab_need_iommu_mapping() then this would race
+ * with a concurrent mapcount() call (on an unmap, for example)
+ * and a lock is required.
+ */
 mt = &maptrack_entry(lgt, handle);
 mt->domid = op->dom;
 mt->ref   = op->ref;
-mt->flags = op->flags;
+wmb();
+write_atomic(&mt->flags, op->flags);

-double_gt_unlock(lgt, rgt);
+if ( gnttab_need_iommu_mapping(ld) )
+double_gt_unlock(lgt, rgt);

 op->dev_bus_addr = (u64)frame << PAGE_SHIFT;
 op->handle   = handle;

David

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

Re: [Xen-devel] Kernel panic, reboot in 5 seconds

[Dario Faggioli]

On Thu, 2015-05-21 at 15:06 +0200, Mr Idris wrote:
> On 5/18/15, George Dunlap  wrote:

> >> (XEN) Xen call trace:
> >> (XEN)[] schedule+0x408/0x5df
> >> (XEN)[] __do_softirq+0x81/0x8c
> >> (XEN)[] do_softirq+0x13/0x15
> >> (XEN)[] idle_loop+0x64/0x74
> >> (XEN)
> >> (XEN) Pagetable walk from 00c8:
> >> (XEN)  L4[0x000] = 000215507063 
> >> (XEN)  L3[0x000] = 000215506063 
> >> (XEN)  L2[0x000] = 000215505063 
> >> (XEN)  L1[0x000] =  
> >> (XEN)
> >> (XEN) 
> >> (XEN) Panic on CPU 0:
> >> (XEN) FATAL PAGE FAULT
> >> (XEN) [error_code=]
> >> (XEN) Faulting linear address: 00c8
> >> (XEN) 
> >> (XEN)
> >> (XEN) Reboot in five seconds...
> >> (XEN) Debugging connection not set up.
> >
> > Fundamentally, the bug you're getting is that you're dereferencing a
> > null pointer, probably into a struct (that's the "Faulting linear
> > address" -- 0xc8 will be the offset into the struct).

> Thanks for the information.
> 
> I'm still confuse with the do_schedule() on each scheduler in xen.
> There are 2 parameters that i think the most important to build simple
> scheduler, ret.time and ret.task.
>
ret.migrated as well, as per:

struct task_slice {
struct vcpu *task;
s_time_t time;
bool_t   migrated;
};

in xen/include/xen/sched-if.h.

It's important for decidine whether we need to call sched_move_irqs().

> ret.time is the time that is set for the VCPU, anyVCPU which run.
>
I can't parse this sentence (or, at least, I can't be sure I'm parsing
it right).

ret.time is the next time instant you want a timer to fire, as you can
see right below the call do sched->do_schedule(), in schedule.c. That
timer, when firing, will cause the scheduler to run again, as it also
can be easily seen in schedule.c, checking out occurrences of s_timer
and s_timer_fn.

> ret.task is the context or domain that should be run/scheduled. Am i correct?
>
It's the vcpu to be run next, yes.

> Or where can i set which domain/process/context should run first?
> 
I'm not sure I'm getting this either... IIUIC, that is what you should
do in your implementation of the do_schedule hook, for your scheduler.

I mean, Credit does it in csched_schedule(), Credit2 in
csched2_schedule(), RTDS in rt_schedule(), ARINC653 in
a653sched_do_schedule().

But maybe I'm missing what you mean with "should run *first*".

BTW, what's the purpose of the new scheduler you're working on, if I can
ask?

Regards,
Dario


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

Re: [Xen-devel] [PATCH V3 6/6] refactor codes to unify pvusb and qemu emulated usb

[George Dunlap]

On Sun, Apr 19, 2015 at 4:50 AM, Chunyan Liu  wrote:
> Now we have pvusb implementation. To merge with future qemu emulated
> usb work, refactor codes:
>  - define 'protocol' (type) to indicate pvusb or qemu, add 'protocol' to
> usb controller and usb device structures, add 'type' to xl interface
> usb-attach|detach.
>  - extract common codes for both qemu and pvusb from libxl_pvusb.c to
> libxl_usb.c, and adjust libxl_pvusb.c codes accordingly.
>
> Signed-off-by: Chunyan Liu 

Thank you for doing this, Chunyan.

A couple of things.

First, I'm not really a fan of having a patch in a series go through
and rearrange things like this; it seems like it would be better to
fold these changes into patches 3-5 of this series.

Second, I've got a number of comments on the "refactoring" bit -- what
you move into libxl_usb.c and how.  But the refactoring bit isn't
really for your feature, and I'll probably have to adjust it anyway
when I actually go to add the qemu side; it seems a bit unfair and a
bit inefficient to ask you to redo the refactoring at this point.

On the other hand, I don't like the idea of checking in an interface
that I know I don't want set in stone, particularly with less than 2
months left until the code freeze.

So what about this: Take the interface-related changes from this patch
(with my comments) and move them back to the earlier patches in the
series; and then just put the minimum amount of code in those patches
to handle them.  The interface is an enum, so if there's only one
option, you should be able to assume that protocol==PV; and it should
be OK internally to assume that all controllers and devices are
actually PV.  Leave the file named "libxl_pvusb.c", but don't bother
(yet) adding a libxl_usb.c.  I'll do that when I add the HVM side of
things.

What do you think?

Further comments below...

> ---
>  tools/libxl/Makefile |   2 +-
>  tools/libxl/libxl_internal.h |   4 +
>  tools/libxl/libxl_pvusb.c| 169 +---
>  tools/libxl/libxl_types.idl  |  11 +++
>  tools/libxl/libxl_usb.c  | 224 
> +++
>  tools/libxl/xl_cmdimpl.c |  54 +--
>  tools/libxl/xl_cmdtable.c|   4 +-
>  7 files changed, 293 insertions(+), 175 deletions(-)
>  create mode 100644 tools/libxl/libxl_usb.c
>
> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
> index d52281f..f786fcf 100644
> --- a/tools/libxl/Makefile
> +++ b/tools/libxl/Makefile
> @@ -95,7 +95,7 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o 
> libxl_pci.o \
> libxl_internal.o libxl_utils.o libxl_uuid.o \
> libxl_json.o libxl_aoutils.o libxl_numa.o 
> libxl_vnuma.o \
> libxl_save_callout.o _libxl_save_msgs_callout.o \
> -   libxl_qmp.o libxl_event.o libxl_fork.o libxl_pvusb.o 
> $(LIBXL_OBJS-y)
> +   libxl_qmp.o libxl_event.o libxl_fork.o libxl_pvusb.o 
> libxl_usb.o $(LIBXL_OBJS-y)
>  LIBXL_OBJS += libxl_genid.o
>  LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
>
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index f426ed8..2ee058b 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -2428,6 +2428,10 @@ _hidden int libxl__device_usbctrl_add(libxl__gc *gc, 
> uint32_t domid,
>  _hidden int libxl__device_usb_add(libxl__gc *gc, uint32_t domid,
>  libxl_device_usb *usb);
>  _hidden int libxl__device_usb_destroy_all(libxl__gc *gc, uint32_t domid);
> +_hidden bool pv_is_usb_assigned(libxl__gc *gc, libxl_device_usb *usb);
> +_hidden int pv_usb_add(libxl__gc *gc, uint32_t domid, libxl_device_usb *usb);
> +_hidden int pv_usb_remove(libxl__gc *gc, uint32_t domid, libxl_device_usb 
> *usb);
> +_hidden int pv_usb_destroy_all(libxl__gc *gc, uint32_t domid);
>
>  /* Internal function to connect a vkb device */
>  _hidden int libxl__device_vkb_add(libxl__gc *gc, uint32_t domid,
> diff --git a/tools/libxl/libxl_pvusb.c b/tools/libxl/libxl_pvusb.c
> index 4e4975a..3dfd2bd 100644
> --- a/tools/libxl/libxl_pvusb.c
> +++ b/tools/libxl/libxl_pvusb.c
> @@ -16,8 +16,6 @@
>
>  #define USBBACK_INFO_PATH "/libxl/usbback"
>
> -#define USBHUB_CLASS_CODE 0x09
> -
>  static int libxl__device_usbctrl_setdefault(libxl__gc *gc, uint32_t domid,
>  libxl_device_usbctrl *usbctrl)
>  {
> @@ -338,6 +336,7 @@ int libxl_device_usbctrl_getinfo(libxl_ctx *ctx, uint32_t 
> domid,
>  usbctrlinfo->devid = usbctrl->devid;
>  usbctrlinfo->ports = usbctrl->ports;
>  usbctrlinfo->version = usbctrl->version;
> +usbctrlinfo->protocol = usbctrl->protocol;

Simillar to my comment on patch 3/6: this should only read
usbctrl->devid.  Here you can assume protocol=PV for the time being.

> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index a6db614..df56303 100644
> --- a/tools/libxl/libx

Re: [Xen-devel] [PATCH V3 4/6] xl: add pvusb commands

[Juergen Gross]

On 05/21/2015 04:00 PM, George Dunlap wrote:

On 05/21/2015 02:55 PM, Juergen Gross wrote:

On 05/21/2015 03:43 PM, George Dunlap wrote:

On 05/21/2015 02:08 PM, Juergen Gross wrote:

On 05/21/2015 03:01 PM, George Dunlap wrote:

On 05/21/2015 12:58 PM, Juergen Gross wrote:

There might be existing users who know about "xm usb-assignable-list".


Yes -- unfortunately something has to give: either we confuse new users
with two names that sound similar but do something different, or we
confuse former xm users by renaming their function, or we confuse
current xl users by renaming their function.  There's badness to be had
whichever one we choose.  I think renaming the xm function is the least
bad of all the options.


OTOH I don't care giving it another name, as long as the functionality
is available.


OK -- what about "usb-available-list"?  Any objections / alternate
suggestions from anyone?


Hmm, just another idea:

xl usb-list -a

could list all domains with assigned USB-devices and the currently not
assigned devices as well. This would avoid the need for another command
name. It would even be possible to omit the "-a".


That works for me too, I guess.

Can I suggest, though, that work on that functionality be detached from
getting the core pvusb functionality in?  I can't really effectively do
the qemu side until it is in due to the cost of rebasing, and I would
really like to have both in for 4.6 if possible.


Sure.

I hope to have my pvusb backend in qemu ready until then, too. :-)
In case the performance isn't too bad I'll have to make some changes to
the libxl part as well, but this will result in some deletions only
(qemu will do driver unbinding, this will no longer be required to be
done by libxl).


Right -- just like it's not necessary when qemu does emulated device
passthrough. :-)

Out of curiosity, what's the motivation for doing pvusb in qemu?  Will
there be an option, for instance, to switch usb devices from emulated
over to pv when the magic port is written to (as is done with disks &
network currently)?


Doing it in qemu was a request when I sent my patches to do it in the
kernel. :-)

Doing pvusb in qemu really has advantages. Just by using a newer Xen
you'll have pvusb backend support in Dom0. No need for a kernel update.

Up to now I have no plan doing a switch of emulated USB devices to pv.
TBH I don't think this is an important scenario. In case someone wants
to add support for it I won't object. :-)


Juergen

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

Re: [Xen-devel] [PATCH v9 1/6] tools/libxl: Check if fdt_{first, next}_subnode are present in libfdt

[Ian Campbell]

On Wed, 2015-05-20 at 13:59 +0100, Julien Grall wrote:
> [...]
> From d4f0ea84f26649b61bc6afb550348069b71d41c5 Mon Sep 17 00:00:00 2001
> From: Julien Grall 
> Date: Tue, 17 Mar 2015 17:58:14 +
> Subject: [PATCH] tools/libxl: Check if fdt_{first,next}_subnode are present in
>  libfdt
> 
> The functions fdt_{first,next}_subnode may not be available because:
> * It has been introduced in 2013 => Doesn't work on Wheezy
> * The prototype exists but the functions are not exposed. Don't ask
> why...
> 
> The later has been fixed recently in the dtc repo [1]

But the bug is still present in 1.4.0, right? Hence this patch is not
obsolete even given the next one.



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

Re: [Xen-devel] [PATCHv9 1/4] gnttab: per-active entry locking

[David Vrabel]

On 21/05/15 08:46, Jan Beulich wrote:
 On 20.05.15 at 17:54,  wrote:
>> @@ -702,6 +729,7 @@ __gnttab_map_grant_ref(
>>  
>>  cache_flags = (shah->flags & (GTF_PAT | GTF_PWT | GTF_PCD) );
>>  
>> +active_entry_release(act);
>>  spin_unlock(&rgt->lock);
> 
> Just for my understanding: The lock isn't meant to also cover *shah?
> I.e. it could be dropped ahead of the cache_flags assignment?

I think so, but I think it's preferable (for now) to keep the locked
regions as-is where possible.

There are few other places where it looked like the locked regions can
be reduced.  It won't really make much difference though since the read
lock and active entry locks are not contented.

>> @@ -978,7 +1009,7 @@ __gnttab_unmap_common(
>>  if ( (rc = replace_grant_host_mapping(op->host_addr,
>>op->frame, op->new_addr, 
>>op->flags)) < 0 )
>> -goto unmap_out;
>> +goto act_release_out;
>>  
>>  ASSERT(act->pin & (GNTPIN_hstw_mask | GNTPIN_hstr_mask));
>>  op->map->flags &= ~GNTMAP_host_map;
> 
> act doesn't look to be accessed anymore after the if() this is
> contained in - why don't you drop the lock as early as possible?
> Or wait - do we need act->pin to remain stable until after that
> subsequent if() (in which case dropping the lock before the
> final if() in the function would mainly make error handling more
> cumbersome without bying us much)?

See comment above.

David

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