Re: [Xen-devel] Help with: Xen BUG at timer.c:189

2017-06-09 Thread Dietmar Hahn 
Am Mittwoch, 7. Juni 2017, 04:28:33 schrieb Jan Beulich:
> >>> On 07.06.17 at 11:28,  wrote:
> > Am Freitag, 19. Mai 2017, 06:41:36 schrieb Jan Beulich:
> >> >>> On 19.05.17 at 11:52,  wrote:
> >> > I'am struggling with a hypervisor panic. The hypervisor version is 4.4.3,
> >> > yes I know - very old ;-), but the affected code hasn't much changed.
> >> 
> >> Well, at the very least I'd expect you to base your code on
> >> 4.4.4 plus the about 199 backports we've added there over time
> >> (assuming yours is based on ours), some of which are scheduler
> >> ones.
> > 
> > Don't you have older versions in the field?
> 
> We certainly do, but when people run into problems first thing
> support is supposed to do is tell them to update.
> 
> >> > The panic was never seen before and occured while booting the system,
> >> > only dom0 was running.
> >> > 
> >> > (XEN) Xen BUG at timer.c:189
> >> > (XEN) [ Xen-4.4.3_02-26.2_x3  x86_64  debug=n  Tainted:C ]
> >> > (XEN) CPU:14
> >> > (XEN) RIP:e008:[] remove_entry+0x26/0x80
> >> > (XEN) RFLAGS: 00010086   CONTEXT: hypervisor
> >> > (XEN) rax: 00bc   rbx: 830839bcd5c8   rcx: 
> >> > 82d080343a80
> >> > (XEN) rdx: d5f0   rsi: 002887fa   rdi: 
> >> > 830839bcd5c8
> >> > (XEN) rbp: d5f0   rsp: 830839bbfe20   r8:  
> >> > 002887211398
> >> > (XEN) r9:  00288721132f   r10: bf8b2994   r11: 
> >> > 82d08011cfa0
> >> > (XEN) r12: 830839bcd5c8   r13: 82d080343a80   r14: 
> >> > d5f0
> >> > (XEN) r15: 82d080343a80   cr0: 8005003b   cr4: 
> >> > 001526f0
> >> > (XEN) cr3: 75679000   cr2: 0069b8ec
> >> > (XEN) ds: 002b   es: 002b   fs:    gs:    ss: e010   cs: e008
> >> > (XEN) Xen stack trace from rsp=830839bbfe20:
> >> > (XEN)830839bcb020 82d08012d3a8 002887fa 
> >> > 0286
> >> > (XEN)830839bcd5f0 830839bcd9c0 002887c1915d 
> >> > 000e
> >> > (XEN)82d080343a70 0002 830839bcda30 
> >> > 82d0801affd0
> >> > (XEN)0001000e 0028872113f4  
> >> > 82d08030fc00
> >> > (XEN)82d0802ffc00 82d080189a1c  
> >> > 
> >> > (XEN) 107800076e92 82d0801292aa 
> >> > 830839bb8000
> >> > (XEN)8300754fd000 82d08031abe0  
> >> > 830839bcb048
> >> > (XEN) 82d080161ad6 0001 
> >> > 
> >> > (XEN)   
> >> > 0009
> >> > (XEN)8803dda20010 0246  
> >> > fffe
> >> > (XEN)  800033aa 
> >> > 
> >> > (XEN) 0001 0100 
> >> > 800033aa
> >> > (XEN)e033 0246 8803dda21f08 
> >> > e02b
> >> > (XEN)   
> >> > 
> >> > (XEN)000e 8300754fd000 0037b9887700 
> >> > 
> >> > (XEN) Xen call trace:
> >> > (XEN)[] remove_entry+0x26/0x80
> >> > (XEN)[] set_timer+0x178/0x230
> >> > (XEN)[] mwait_idle+0x270/0x370
> >> > (XEN)[] local_time_calibration+0x19c/0x1a0
> >> > (XEN)[] __do_softirq+0x6a/0xa0
> >> > (XEN)[] idle_loop+0x16/0x50
> >> > (XEN) 
> >> > (XEN) 
> >> > (XEN) 
> >> > (XEN) Panic on CPU 14:
> >> > (XEN) Xen BUG at timer.c:189
> >> > (XEN) 
> >> > (XEN) 
> >> > (XEN) Reboot in five seconds...
> >> > (XEN) Executing kexec image on cpu14
> >> > (XEN) Shot down all CPUs
> >> > 
> >> > This is the call of BUG() in remove_entry() in case timer->status is not
> >> > TIMER_STATUS_in_heap or TIMER_STATUS_in_list.
> >> > 
> >> > With the address of the timer from the vmcore:
> >> > crash> struct timer 830839bcd5c8
> >> > struct timer {
> >> >   expires = 0,
> >> >   {
> >> > heap_offset = 968676784, 
> >> > list_next = 0x830839bcd5b0, 
> >> > inactive = {
> >> >   next = 0x830839bcd5b0, 
> >> >   prev = 0x20020020050
> >> > }
> >> >   }, 
> >> >   function = 0x830839bcd5e0, 
> >> >   data = 0x830839bcd5e0, 
> >> >   cpu = 54768, 
> >> >   status = 188 '\274'
> >> > }
> >> > 
> >> > This looks like the structure was overwritten.
> >> > 
> >> > The call path seems to be:
> >> >  mwait_idle()
> >> >sched_tick_resume()
> >> >  csched_tick_resume()
> >> >set_timer()
> >> >  remove_timer()
> >> > 
> >> > In sched_tick_resume():
> >> >  unsigned int cpu = smp_processor_id();
> >> > 
> >> > I extracted struct cpu_info from the stack and found:
> >> > crash> cpu_info 830839bbff18
>

Re: [Xen-devel] Help with: Xen BUG at timer.c:189

2017-06-07 Thread Dietmar Hahn 
Am Freitag, 19. Mai 2017, 06:41:36 schrieb Jan Beulich:
> >>> On 19.05.17 at 11:52,  wrote:
> > I'am struggling with a hypervisor panic. The hypervisor version is 4.4.3,
> > yes I know - very old ;-), but the affected code hasn't much changed.
> 
> Well, at the very least I'd expect you to base your code on
> 4.4.4 plus the about 199 backports we've added there over time
> (assuming yours is based on ours), some of which are scheduler
> ones.

Don't you have older versions in the field?

> 
> > The panic was never seen before and occured while booting the system,
> > only dom0 was running.
> > 
> > (XEN) Xen BUG at timer.c:189
> > (XEN) [ Xen-4.4.3_02-26.2_x3  x86_64  debug=n  Tainted:C ]
> > (XEN) CPU:14
> > (XEN) RIP:e008:[] remove_entry+0x26/0x80
> > (XEN) RFLAGS: 00010086   CONTEXT: hypervisor
> > (XEN) rax: 00bc   rbx: 830839bcd5c8   rcx: 82d080343a80
> > (XEN) rdx: d5f0   rsi: 002887fa   rdi: 830839bcd5c8
> > (XEN) rbp: d5f0   rsp: 830839bbfe20   r8:  002887211398
> > (XEN) r9:  00288721132f   r10: bf8b2994   r11: 82d08011cfa0
> > (XEN) r12: 830839bcd5c8   r13: 82d080343a80   r14: d5f0
> > (XEN) r15: 82d080343a80   cr0: 8005003b   cr4: 001526f0
> > (XEN) cr3: 75679000   cr2: 0069b8ec
> > (XEN) ds: 002b   es: 002b   fs:    gs:    ss: e010   cs: e008
> > (XEN) Xen stack trace from rsp=830839bbfe20:
> > (XEN)830839bcb020 82d08012d3a8 002887fa 0286
> > (XEN)830839bcd5f0 830839bcd9c0 002887c1915d 000e
> > (XEN)82d080343a70 0002 830839bcda30 82d0801affd0
> > (XEN)0001000e 0028872113f4  82d08030fc00
> > (XEN)82d0802ffc00 82d080189a1c  
> > (XEN) 107800076e92 82d0801292aa 830839bb8000
> > (XEN)8300754fd000 82d08031abe0  830839bcb048
> > (XEN) 82d080161ad6 0001 
> > (XEN)   0009
> > (XEN)8803dda20010 0246  fffe
> > (XEN)  800033aa 
> > (XEN) 0001 0100 800033aa
> > (XEN)e033 0246 8803dda21f08 e02b
> > (XEN)   
> > (XEN)000e 8300754fd000 0037b9887700 
> > (XEN) Xen call trace:
> > (XEN)[] remove_entry+0x26/0x80
> > (XEN)[] set_timer+0x178/0x230
> > (XEN)[] mwait_idle+0x270/0x370
> > (XEN)[] local_time_calibration+0x19c/0x1a0
> > (XEN)[] __do_softirq+0x6a/0xa0
> > (XEN)[] idle_loop+0x16/0x50
> > (XEN) 
> > (XEN) 
> > (XEN) 
> > (XEN) Panic on CPU 14:
> > (XEN) Xen BUG at timer.c:189
> > (XEN) 
> > (XEN) 
> > (XEN) Reboot in five seconds...
> > (XEN) Executing kexec image on cpu14
> > (XEN) Shot down all CPUs
> > 
> > This is the call of BUG() in remove_entry() in case timer->status is not
> > TIMER_STATUS_in_heap or TIMER_STATUS_in_list.
> > 
> > With the address of the timer from the vmcore:
> > crash> struct timer 830839bcd5c8
> > struct timer {
> >   expires = 0,
> >   {
> > heap_offset = 968676784, 
> > list_next = 0x830839bcd5b0, 
> > inactive = {
> >   next = 0x830839bcd5b0, 
> >   prev = 0x20020020050
> > }
> >   }, 
> >   function = 0x830839bcd5e0, 
> >   data = 0x830839bcd5e0, 
> >   cpu = 54768, 
> >   status = 188 '\274'
> > }
> > 
> > This looks like the structure was overwritten.
> > 
> > The call path seems to be:
> >  mwait_idle()
> >sched_tick_resume()
> >  csched_tick_resume()
> >set_timer()
> >  remove_timer()
> > 
> > In sched_tick_resume():
> >  unsigned int cpu = smp_processor_id();
> > 
> > I extracted struct cpu_info from the stack and found:
> > crash> cpu_info 830839bbff18
> > struct cpu_info {
> >   ...
> >   processor_id = 14, 
> >   current_vcpu = 0x8300754fd000, 
> >   per_cpu_offset = 0x37b9887700,
> >   ...
> > 
> > And from the code in sched_credit.c:  spc = CSCHED_PCPU(cpu);
> > I calculated spc:
> > 
> > crash> csched_pcpu 0x830839be2b40
> > struct csched_pcpu {
> >   runq = {
> > next = 0x830839be2b40, 
> > prev = 0x830839be2b40
> >   }, 
> >   runq_sort_last = 0, 
> >   ticker = {
> > expires = 17408000, 
> > {
> >   heap_offset = 1, 
> >   list_next = 0x10010010001, 
> >   inactive = {
> > next = 0x10010010001, 
> > prev = 0x200200200200200
> >   }
> > }, 
> >

Re: [Xen-devel] Schedule is live for the Xen Project’s Annual Conference - Discounted Registration closes by end of May

2017-05-30 Thread Dietmar Hahn 
Hi Lars,

ich habe eine Frage bzgl. der Online-Registrierung. Damit meine Firma die Kosten
übernimmt, muss auf der Rechnung letztendlich die Firmenadresse stehen.
Gibt es am Ende der Registrierung eine Rechnung die auf die Firma lautet?
Danke!

Dietmar.


Am Donnerstag, 25. Mai 2017, 16:09:40 schrieb Lars Kurth:
> Dear Community members,
>  
> Community, embedded, automotive, performance, hardware, and security are a 
> few topics that will be covered during the upcoming Xen Project Developer and 
> Design Summit 
> (http://events.linuxfoundation.org/events/xen-developer-and-design-summit) 
> happening July 11-13 in Budapest, Hungary. 
> 
> You can find the full schedule here: 
> http://events.linuxfoundation.org/events/xen-developer-and-design-summit/program/schedule
>  
> The conference is combines the formats of the Xen Project Developer Summits 
> with the Xen Project Hackathons, with talks in the morning and Design 
> Sessions in the afternoon.
> 
> Here’s a sampling of some of the talks at the Summit:
> * Dedicated Secure Domain as an Approach for Certification of Automotive 
> Sector Solutions from Iurii Mykhalskyi of GlobalLogic
> * Uniprof: Transparent Unikernel Performance Profiling and Debugging from 
> Florian Schmidt of NEC
> * Hypervisor-Based Security: Bringing Virtualized Exceptions Into the Game 
> from Mihai Dontu of Bitdefender
> * Bring up PCI Passthrough on ARM from Julien Grall of ARM
> * Shared Coprocessor Framework on ARM - Oleksandr Andrushchenko, EPAM Systems
> * Secure Containers with Xen and CoreOS rkt - Stefano Stabellini, Aporeto
> * To Grant or Not to Grant? - João Martins, Oracle
>  
> Currently, we have an early bird special ($250), which will end at the end of 
> May (see 
> http://events.linuxfoundation.org/events/xen-developer-and-design-summit/attend/register).
>  Note that the overall ticket price is higher compared to the past, as the 
> event is 3 days long and based on your feedback from last year, we included 
> lunch.
> 
> Also note that you can still submit design sessions: see 
> http://events.linuxfoundation.org/events/xen-developer-and-design-summit/program/cfp-design-session
>  
> Best Regards
> Lars
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel

-- 
Company details: http://ts.fujitsu.com/imprint.html

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

[Xen-devel] Help with: Xen BUG at timer.c:189

2017-05-19 Thread Dietmar Hahn 
Hi list,

I'am struggling with a hypervisor panic. The hypervisor version is 4.4.3,
yes I know - very old ;-), but the affected code hasn't much changed.
The panic was never seen before and occured while booting the system,
only dom0 was running.

(XEN) Xen BUG at timer.c:189
(XEN) [ Xen-4.4.3_02-26.2_x3  x86_64  debug=n  Tainted:C ]
(XEN) CPU:14
(XEN) RIP:e008:[] remove_entry+0x26/0x80
(XEN) RFLAGS: 00010086   CONTEXT: hypervisor
(XEN) rax: 00bc   rbx: 830839bcd5c8   rcx: 82d080343a80
(XEN) rdx: d5f0   rsi: 002887fa   rdi: 830839bcd5c8
(XEN) rbp: d5f0   rsp: 830839bbfe20   r8:  002887211398
(XEN) r9:  00288721132f   r10: bf8b2994   r11: 82d08011cfa0
(XEN) r12: 830839bcd5c8   r13: 82d080343a80   r14: d5f0
(XEN) r15: 82d080343a80   cr0: 8005003b   cr4: 001526f0
(XEN) cr3: 75679000   cr2: 0069b8ec
(XEN) ds: 002b   es: 002b   fs:    gs:    ss: e010   cs: e008
(XEN) Xen stack trace from rsp=830839bbfe20:
(XEN)830839bcb020 82d08012d3a8 002887fa 0286
(XEN)830839bcd5f0 830839bcd9c0 002887c1915d 000e
(XEN)82d080343a70 0002 830839bcda30 82d0801affd0
(XEN)0001000e 0028872113f4  82d08030fc00
(XEN)82d0802ffc00 82d080189a1c  
(XEN) 107800076e92 82d0801292aa 830839bb8000
(XEN)8300754fd000 82d08031abe0  830839bcb048
(XEN) 82d080161ad6 0001 
(XEN)   0009
(XEN)8803dda20010 0246  fffe
(XEN)  800033aa 
(XEN) 0001 0100 800033aa
(XEN)e033 0246 8803dda21f08 e02b
(XEN)   
(XEN)000e 8300754fd000 0037b9887700 
(XEN) Xen call trace:
(XEN)[] remove_entry+0x26/0x80
(XEN)[] set_timer+0x178/0x230
(XEN)[] mwait_idle+0x270/0x370
(XEN)[] local_time_calibration+0x19c/0x1a0
(XEN)[] __do_softirq+0x6a/0xa0
(XEN)[] idle_loop+0x16/0x50
(XEN) 
(XEN) 
(XEN) 
(XEN) Panic on CPU 14:
(XEN) Xen BUG at timer.c:189
(XEN) 
(XEN) 
(XEN) Reboot in five seconds...
(XEN) Executing kexec image on cpu14
(XEN) Shot down all CPUs

This is the call of BUG() in remove_entry() in case timer->status is not
TIMER_STATUS_in_heap or TIMER_STATUS_in_list.

With the address of the timer from the vmcore:
crash> struct timer 830839bcd5c8
struct timer {
  expires = 0,
  {
heap_offset = 968676784, 
list_next = 0x830839bcd5b0, 
inactive = {
  next = 0x830839bcd5b0, 
  prev = 0x20020020050
}
  }, 
  function = 0x830839bcd5e0, 
  data = 0x830839bcd5e0, 
  cpu = 54768, 
  status = 188 '\274'
}

This looks like the structure was overwritten.

The call path seems to be:
 mwait_idle()
   sched_tick_resume()
 csched_tick_resume()
   set_timer()
 remove_timer()

In sched_tick_resume():
 unsigned int cpu = smp_processor_id();

I extracted struct cpu_info from the stack and found:
crash> cpu_info 830839bbff18
struct cpu_info {
  ...
  processor_id = 14, 
  current_vcpu = 0x8300754fd000, 
  per_cpu_offset = 0x37b9887700,
  ...

And from the code in sched_credit.c:  spc = CSCHED_PCPU(cpu);
I calculated spc:

crash> csched_pcpu 0x830839be2b40
struct csched_pcpu {
  runq = {
next = 0x830839be2b40, 
prev = 0x830839be2b40
  }, 
  runq_sort_last = 0, 
  ticker = {
expires = 17408000, 
{
  heap_offset = 1, 
  list_next = 0x10010010001, 
  inactive = {
next = 0x10010010001, 
prev = 0x200200200200200
  }
}, 
function = 0x82d08011f200 , 
data = 0xe, 
cpu = 14, 
status = 3 '\003'
  }, 
  tick = 0, 
  idle_bias = 47, 
  balance_mask = 0x830839be2bb0
}

And this ticker looks ok!
So the ticker address extracted from the vmcore in remove_entry()
is not the same as the expected one read from the code.

Did I made wrong assumptions when looking at the code/vmcore?
Has anyone seen such a case or has anybody a hint for further investigation?
Any help would be very welcome.

Thanks in advance.
Dietmar.




-- 
Company details: http://ts.fujitsu.com/imprint.html

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

Re: [Xen-devel] [PATCH 1/3] xen/blkback: fix disconnect while I/Os in flight

2017-05-16 Thread Dietmar Hahn 
Am Dienstag, 16. Mai 2017, 08:23:18 schrieb Juergen Gross:
> Today disconnecting xen-blkback is broken in case there are still
> I/Os in flight: xen_blkif_disconnect() will bail out early without
> releasing all resources in the hope it will be called again when
> the last request has terminated. This, however, won't happen as
> xen_blkif_free() won't be called on termination of the last running
> request: xen_blkif_put() won't decrement the blkif refcnt to 0 as
> xen_blkif_disconnect() didn't finish before thus some xen_blkif_put()
> calls in xen_blkif_disconnect() didn't happen.
> 
> To solve this deadlock xen_blkif_disconnect() and
> xen_blkif_alloc_rings() shouldn't use xen_blkif_put() and
> xen_blkif_get() but use some other way to do their accounting of
> resources.
> 
> This at once fixes another error in xen_blkif_disconnect(): when it
> returned early with -EBUSY for another ring than 0 it would call
> xen_blkif_put() again for already handled rings on a subsequent call.
> This will lead to inconsistencies in the refcnt handling.
> 
> Cc: sta...@vger.kernel.org
> Reported-by: Glenn Enright 
> Signed-off-by: Juergen Gross 
> Tested-by: Steven Haigh 
> ---
>  drivers/block/xen-blkback/common.h | 1 +
>  drivers/block/xen-blkback/xenbus.c | 7 +--
>  2 files changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/block/xen-blkback/common.h 
> b/drivers/block/xen-blkback/common.h
> index dea61f6ab8cb..953f38802333 100644
> --- a/drivers/block/xen-blkback/common.h
> +++ b/drivers/block/xen-blkback/common.h
> @@ -281,6 +281,7 @@ struct xen_blkif_ring {
>  
>   wait_queue_head_t   wq;
>   atomic_tinflight;
> + int active;

Maybe better using bool?

Dietmar.

>   /* One thread per blkif ring. */
>   struct task_struct  *xenblkd;
>   unsigned intwaiting_reqs;
> diff --git a/drivers/block/xen-blkback/xenbus.c 
> b/drivers/block/xen-blkback/xenbus.c
> index 1f3dfaa54d87..e68df9de8858 100644
> --- a/drivers/block/xen-blkback/xenbus.c
> +++ b/drivers/block/xen-blkback/xenbus.c
> @@ -159,7 +159,7 @@ static int xen_blkif_alloc_rings(struct xen_blkif *blkif)
>   init_waitqueue_head(>shutdown_wq);
>   ring->blkif = blkif;
>   ring->st_print = jiffies;
> - xen_blkif_get(blkif);
> + ring->active = 1;
>   }
>  
>   return 0;
> @@ -249,6 +249,9 @@ static int xen_blkif_disconnect(struct xen_blkif *blkif)
>   struct xen_blkif_ring *ring = >rings[r];
>   unsigned int i = 0;
>  
> + if (!ring->active)
> + continue;
> +
>   if (ring->xenblkd) {
>   kthread_stop(ring->xenblkd);
>   wake_up(>shutdown_wq);
> @@ -296,7 +299,7 @@ static int xen_blkif_disconnect(struct xen_blkif *blkif)
>   BUG_ON(ring->free_pages_num != 0);
>   BUG_ON(ring->persistent_gnt_c != 0);
>   WARN_ON(i != (XEN_BLKIF_REQS_PER_PAGE * blkif->nr_ring_pages));
> - xen_blkif_put(blkif);
> + ring->active = 0;
>   }
>   blkif->nr_ring_pages = 0;
>   /*
> 

-- 
Company details: http://ts.fujitsu.com/imprint.html

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

Re: [Xen-devel] null domains after xl destroy

2017-04-11 Thread Dietmar Hahn 
Am Dienstag, 11. April 2017, 20:03:14 schrieb Glenn Enright:
> On 11/04/17 17:59, Juergen Gross wrote:
> > On 11/04/17 07:25, Glenn Enright wrote:
> >> Hi all
> >>
> >> We are seeing an odd issue with domu domains from xl destroy, under
> >> recent 4.9 kernels a (null) domain is left behind.
> >
> > I guess this is the dom0 kernel version?
> >
> >> This has occurred on a variety of hardware, with no obvious commonality.
> >>
> >> 4.4.55 does not show this behavior.
> >>
> >> On my test machine I have the following packages installed under
> >> centos6, from https://xen.crc.id.au/
> >>
> >> ~]# rpm -qa | grep xen
> >> xen47-licenses-4.7.2-4.el6.x86_64
> >> xen47-4.7.2-4.el6.x86_64
> >> kernel-xen-4.9.21-1.el6xen.x86_64
> >> xen47-ocaml-4.7.2-4.el6.x86_64
> >> xen47-libs-4.7.2-4.el6.x86_64
> >> xen47-libcacard-4.7.2-4.el6.x86_64
> >> xen47-hypervisor-4.7.2-4.el6.x86_64
> >> xen47-runtime-4.7.2-4.el6.x86_64
> >> kernel-xen-firmware-4.9.21-1.el6xen.x86_64
> >>
> >> I've also replicated the issue with 4.9.17 and 4.9.20
> >>
> >> To replicate, on a cleanly booted dom0 with one pv VM, I run the
> >> following on the VM
> >>
> >> {
> >> while true; do
> >>  dd bs=1M count=512 if=/dev/zero of=test conv=fdatasync
> >> done
> >> }
> >>
> >> Then on the dom0 I do this sequence to reliably get a null domain. This
> >> occurs with oxenstored and xenstored both.
> >>
> >> {
> >> xl sync 1
> >> xl destroy 1
> >> }
> >>
> >> xl list then renders something like ...
> >>
> >> (null)   1 4 4 --p--d
> >> 9.8 0
> >
> > Something is referencing the domain, e.g. some of its memory pages are
> > still mapped by dom0.

You can try
# xl debug-keys q
and further
# xl dmesg
to see the output of the previous command. The 'q' dumps domain
(and guest debug) info.
# xl debug-keys h
prints all possible parameters for more informations.

Dietmar.

> >
> >> From what I can see it appears to be disk related. Affected VMs all use
> >> lvm storage for their boot disk. lvdisplay of the affected lv shows that
> >> the lv has is being help open by something.
> >
> > How are the disks configured? Especially the backend type is important.
> >
> >>
> >> ~]# lvdisplay test/test.img | grep open
> >>   # open 1
> >>
> >> I've not been able to determine what that thing is as yet. I tried lsof,
> >> dmsetup, various lv tools. Waiting for the disk to be released does not
> >> work.
> >>
> >> ~]# xl list
> >> NameID   Mem VCPUs  State
> >> Time(s)
> >> Domain-0 0  1512 2 r-
> >> 29.0
> >> (null)   1 4 4 --p--d
> >> 9.8
> >>
> >> xenstore-ls reports nothing for the null domain id that I can see.
> >
> > Any qemu process related to the domain still running?
> >
> > Any dom0 kernel messages related to Xen?
> >
> >
> > Juergen
> >
> 
> Yep, 4.9 dom0 kernel
> 
> Typically we see an xl process running, but that has already gone away 
> in this case. The domU is a PV guest using phy definition, the basic 
> startup is like this...
> 
> xl -v create -f paramfile extra="console=hvc0 elevator=noop 
> xen-blkfront.max=64"
> 
> There are no qemu processes or threads anywhere I can see.
> 
> I dont see any meaningful messages in the linux kernel log, and nothing 
> at all in the hypervisor log. Here is output from the dom0 starting and 
> then stopping a domU using the above mechanism
> 
> br0: port 2(vif3.0) entered disabled state
> br0: port 2(vif4.0) entered blocking state
> br0: port 2(vif4.0) entered disabled state
> device vif4.0 entered promiscuous mode
> IPv6: ADDRCONF(NETDEV_UP): vif4.0: link is not ready
> xen-blkback: backend/vbd/4/51713: using 2 queues, protocol 1 
> (x86_64-abi) persistent grants
> xen-blkback: backend/vbd/4/51721: using 2 queues, protocol 1 
> (x86_64-abi) persistent grants
> vif vif-4-0 vif4.0: Guest Rx ready
> IPv6: ADDRCONF(NETDEV_CHANGE): vif4.0: link becomes ready
> br0: port 2(vif4.0) entered blocking state
> br0: port 2(vif4.0) entered forwarding state
> br0: port 2(vif4.0) entered disabled state
> br0: port 2(vif4.0) entered disabled state
> device vif4.0 left promiscuous mode
> br0: port 2(vif4.0) entered disabled state
> 
> ... here is xl info ...
> 
> host   : 
> release: 4.9.21-1.el6xen.x86_64
> version: #1 SMP Sat Apr 8 18:03:45 AEST 2017
> machine: x86_64
> nr_cpus: 4
> max_cpu_id : 3
> nr_nodes   : 1
> cores_per_socket   : 4
> threads_per_core   : 1
> cpu_mhz: 2394
> hw_caps: 
> b7ebfbff:e3bd:20100800:0001::::
> virt_caps  :
> total_memory   : 8190
> free_memory: 6577
> sharing_freed_memory   : 0
> sharing_used_memory: 0
> outstanding_claims : 0
> free_cpus  : 0
> xen_major

Re: [Xen-devel] [PATCH v2 0/3] VPMU fixes

2015-12-02 Thread Dietmar Hahn 
Am Mittwoch 02 Dezember 2015, 02:20:49 schrieb Tian, Kevin:
> > From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
> > Sent: Wednesday, December 02, 2015 12:50 AM
> > 
> > * Limit VPMU support to PMU versions 2, 3 and 4 (emulated at version 3 
> > level)
> > * Always implement family 6 VPMU quirk.
> >   ==>  Intel folks: is the quirk needed for all family 6 processors or can 
> > we
> > limit it to certain models?
> 
> Let me confirm this information internally. btw could you provide a link
> where you find out the original quirk information?

http://old-list-archives.xenproject.org/xen-devel/2010-11/msg01157.html
Dietmar.

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

-- 
Company details: http://ts.fujitsu.com/imprint.html

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

Re: [Xen-devel] [PATCH 1/2] x86/VPMU: Support only versions 2 and 3 of architectural performance monitoring

2015-12-01 Thread Dietmar Hahn 
Am Montag 30 November 2015, 13:38:40 schrieb Boris Ostrovsky:
> We need to have at least version 2 since it's the first version to
> support various control and status registers (such as
> MSR_CORE_PERF_GLOBAL_CTRL) that VPMU relies on always having.
> 
> With explicit testing for PMU version we can now remove CPUID model
> check.
> 
> Signed-off-by: Boris Ostrovsky 
> ---
>  xen/arch/x86/cpu/vpmu_intel.c | 55 
> +++
>  1 file changed, 8 insertions(+), 47 deletions(-)
> 
> diff --git a/xen/arch/x86/cpu/vpmu_intel.c b/xen/arch/x86/cpu/vpmu_intel.c
> index d5ea7fe..bb4ddcc 100644
> --- a/xen/arch/x86/cpu/vpmu_intel.c
> +++ b/xen/arch/x86/cpu/vpmu_intel.c
> @@ -955,59 +955,20 @@ int vmx_vpmu_initialise(struct vcpu *v)
>  int __init core2_vpmu_init(void)
>  {
>  u64 caps;
> +unsigned int version = 0;
>  
> -if ( current_cpu_data.x86 != 6 )
> +if ( current_cpu_data.cpuid_level >= 0xa )
> +version = cpuid_eax(0xa) & 0xff;
> +if ( (version != 2) && (version != 3) )
>  {
> -printk(XENLOG_WARNING "VPMU: only family 6 is supported\n");
> +printk(XENLOG_WARNING "VPMU: version %d is not supported\n", 
> version);
>  return -EINVAL;

But this means that all (newer?) processors with version=4 are not supported
even though the SDM 3B tells:
"Processors supporting architectural performance monitoring version 4 also
 supports version 1, 2, and 3, ..."

Shold we not only write a hint that version 4 capabilities are not supported
and fake this cpuid-flag for the guests to the version 3?

Dietmar.

>  }
>  
> -switch ( current_cpu_data.x86_model )
> +if ( current_cpu_data.x86 != 6 )
>  {
> -/* Core2: */
> -case 0x0f: /* original 65 nm celeron/pentium/core2/xeon, 
> "Merom"/"Conroe" */
> -case 0x16: /* single-core 65 nm celeron/core2solo 
> "Merom-L"/"Conroe-L" */
> -case 0x17: /* 45 nm celeron/core2/xeon "Penryn"/"Wolfdale" */
> -case 0x1d: /* six-core 45 nm xeon "Dunnington" */
> -
> -case 0x2a: /* SandyBridge */
> -case 0x2d: /* SandyBridge, "Romley-EP" */
> -
> -/* Nehalem: */
> -case 0x1a: /* 45 nm nehalem, "Bloomfield" */
> -case 0x1e: /* 45 nm nehalem, "Lynnfield", "Clarksfield", "Jasper 
> Forest" */
> -case 0x2e: /* 45 nm nehalem-ex, "Beckton" */
> -
> -/* Westmere: */
> -case 0x25: /* 32 nm nehalem, "Clarkdale", "Arrandale" */
> -case 0x2c: /* 32 nm nehalem, "Gulftown", "Westmere-EP" */
> -case 0x2f: /* 32 nm Westmere-EX */
> -
> -case 0x3a: /* IvyBridge */
> -case 0x3e: /* IvyBridge EP */
> -
> -/* Haswell: */
> -case 0x3c:
> -case 0x3f:
> -case 0x45:
> -case 0x46:
> -
> -/* Broadwell */
> -case 0x3d:
> -case 0x4f:
> -case 0x56:
> -
> -/* future: */
> -case 0x4e:
> -
> -/* next gen Xeon Phi */
> -case 0x57:
> -break;
> -
> -default:
> -printk(XENLOG_WARNING "VPMU: Unsupported CPU model %#x\n",
> -   current_cpu_data.x86_model);
> -return -EINVAL;
> +printk(XENLOG_WARNING "VPMU: only family 6 is supported\n");
> +return -EINVAL;
>  }
>  
>  arch_pmc_cnt = core2_get_arch_pmc_count();
> 

-- 
Company details: http://ts.fujitsu.com/imprint.html

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

Re: [Xen-devel] [PATCH v2 2/2] x86/VPMU: implement ipc and arch filter flags

2015-11-26 Thread Dietmar Hahn 
Am Dienstag 24 November 2015, 15:53:12 schrieb Brendan Gregg:
> This introduces a way to have a restricted VPMU, by specifying one of two
> predefined groups of PMCs to make available. For secure environments, this
> allows the VPMU to be used without needing to enable all PMCs.
> 
> Signed-off-by: Brendan Gregg 
> ---
>  docs/misc/xen-command-line.markdown | 14 +-
>  xen/arch/x86/cpu/vpmu.c | 51 
> +
>  xen/arch/x86/cpu/vpmu_intel.c   | 48 ++
>  xen/include/asm-x86/msr-index.h |  1 +
>  xen/include/public/pmu.h| 14 --
>  5 files changed, 115 insertions(+), 13 deletions(-)
> 
> diff --git a/docs/misc/xen-command-line.markdown 
> b/docs/misc/xen-command-line.markdown
> index 70daa84..6055a68 100644
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -1452,7 +1452,7 @@ Use Virtual Processor ID support if available.  This 
> prevents the need for TLB
>  flushes on VM entry and exit, increasing performance.
>  
>  ### vpmu
> -> `= ( bts )`
> +> `= (  | { bts | ipc | arch [, ...] } )`
>  
>  > Default: `off`
>  
> @@ -1468,6 +1468,18 @@ wrong behaviour (see handle\_pmc\_quirk()).
>  If 'vpmu=bts' is specified the virtualisation of the Branch Trace Store (BTS)
>  feature is switched on on Intel processors supporting this feature.
>  
> +vpmu=ipc enables performance monitoring, but restricts the counters to the
> +most minimum set possible: instructions, cycles, and reference cycles. These
> +can be used to calculate instructions per cycle (IPC).
> +
> +vpmu=arch enables performance monitoring, but restricts the counters to the
> +pre-defined architectural events only. These are exposed by cpuid, and listed
> +in Table 18-1 from the Intel 64 and IA-32 Architectures Software Developer's
> +Manual, Volume 3B, System Programming Guide, Part 2.

Maybe you better should write
section "Pre-defined Architectural Performance Events"
instead of "Table 18-1" because the number may change in the document.
And below in the comment of the code too.

Dietmar.

> +
> +If a boolean is not used, combinations of flags are allowed, comma separated.
> +For example, vpmu=arch,bts.
> +
>  Note that if **watchdog** option is also specified vpmu will be turned off.
>  
>  *Warning:*
> diff --git a/xen/arch/x86/cpu/vpmu.c b/xen/arch/x86/cpu/vpmu.c
> index 2f5156a..bb0ca37 100644
> --- a/xen/arch/x86/cpu/vpmu.c
> +++ b/xen/arch/x86/cpu/vpmu.c
> @@ -43,33 +43,64 @@ CHECK_pmu_data;
>  CHECK_pmu_params;
>  
>  /*
> - * "vpmu" : vpmu generally enabled
> - * "vpmu=off" : vpmu generally disabled
> - * "vpmu=bts" : vpmu enabled and Intel BTS feature switched on.
> + * "vpmu" : vpmu generally enabled (all counters)
> + * "vpmu=off"  : vpmu generally disabled
> + * "vpmu=bts"  : vpmu enabled and Intel BTS feature switched on.
> + * "vpmu=ipc"  : vpmu enabled for IPC counters only (most restrictive)
> + * "vpmu=arch" : vpmu enabled for predef arch counters only (restrictive)
> + * flag combinations are allowed, eg, "vpmu=ipc,bts".
>   */
>  static unsigned int __read_mostly opt_vpmu_enabled;
>  unsigned int __read_mostly vpmu_mode = XENPMU_MODE_OFF;
>  unsigned int __read_mostly vpmu_features = 0;
> -static void parse_vpmu_param(char *s);
> -custom_param("vpmu", parse_vpmu_param);
> +static void parse_vpmu_params(char *s);
> +custom_param("vpmu", parse_vpmu_params);
>  
>  static DEFINE_SPINLOCK(vpmu_lock);
>  static unsigned vpmu_count;
>  
>  static DEFINE_PER_CPU(struct vcpu *, last_vcpu);
>  
> -static void __init parse_vpmu_param(char *s)
> +static int parse_vpmu_param(char *s, int len)
>  {
> +if ( ! *s || ! len )
> +return 0;
> +if ( !strncmp(s, "bts", len) )
> +vpmu_features |= XENPMU_FEATURE_INTEL_BTS;
> +else if ( !strncmp(s, "ipc", len) )
> +vpmu_features |= XENPMU_FEATURE_IPC_ONLY;
> +else if ( !strncmp(s, "arch", len) )
> +vpmu_features |= XENPMU_FEATURE_ARCH_ONLY;
> +else if ( *s )
> +{
> +return 1;
> +}
> +return 0;
> +}
> +
> +static void __init parse_vpmu_params(char *s)
> +{
> +bool_t badflag = 0;
> +char *sep, *p = s;
> +
>  switch ( parse_bool(s) )
>  {
>  case 0:
>  break;
>  default:
> -if ( !strcmp(s, "bts") )
> -vpmu_features |= XENPMU_FEATURE_INTEL_BTS;
> -else if ( *s )
> +sep = strchr(p, ',');
> +while (sep != NULL)
> +{
> +if ( parse_vpmu_param(p, sep - p) )
> +badflag = 1;
> +p = sep + 1;
> +sep = strchr(p, ',');
> +}
> +sep = strchr(p, 0);
> +parse_vpmu_param(p, sep - p);
> +if ( badflag )
>  {
> -printk("VPMU: unknown flag: %s - vpmu disabled!\n", s);
> +printk("VPMU: unknown flags: %s - vpmu disabled!\n", s);
>  break;
>  }
>  /* fall

Re: [Xen-devel] [PATCH v2 1/2] x86/VPMU: return correct fixed PMC count

2015-11-25 Thread Dietmar Hahn 
Am Dienstag 24 November 2015, 15:53:11 schrieb Brendan Gregg:
> Fixes a register typo.
> 
> Signed-off-by: Brendan Gregg <bgr...@netflix.com>
> ---
>  xen/arch/x86/cpu/vpmu_intel.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

Reviewed-by: Dietmar Hahn <dietmar.h...@ts.fujitsu.com>

> 
> diff --git a/xen/arch/x86/cpu/vpmu_intel.c b/xen/arch/x86/cpu/vpmu_intel.c
> index 12f80ae..8d83a1a 100644
> --- a/xen/arch/x86/cpu/vpmu_intel.c
> +++ b/xen/arch/x86/cpu/vpmu_intel.c
> @@ -166,10 +166,10 @@ static int core2_get_arch_pmc_count(void)
>   */
>  static int core2_get_fixed_pmc_count(void)
>  {
> -u32 eax;
> +u32 edx;
>  
> -eax = cpuid_eax(0xa);
> -return MASK_EXTR(eax, PMU_FIXED_NR_MASK);
> +edx = cpuid_edx(0xa);
> +return MASK_EXTR(edx, PMU_FIXED_NR_MASK);
>  }
>  
>  /* edx bits 5-12: Bit width of fixed-function performance counters  */
> 

-- 
Company details: http://ts.fujitsu.com/imprint.html

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

Re: [Xen-devel] [PATCH for 4.6] x86/VPMU: Set VPMU context pointer to NULL when freeing it

2015-09-09 Thread Dietmar Hahn 
Am Dienstag 08 September 2015, 22:55:52 schrieb Boris Ostrovsky:
> Otherwise we may hit assertion in vpmu_initialise() if vcpu is offlined
> and then onlined again.
> 
> For tidyness, set priv_context to NULL as well.

Reviewed-by: Dietmar Hahn <dietmar.h...@ts.fujitsu.com>

> 
> Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com>
> ---
>  xen/arch/x86/cpu/vpmu_amd.c   | 2 ++
>  xen/arch/x86/cpu/vpmu_intel.c | 2 ++
>  2 files changed, 4 insertions(+)
> 
> diff --git a/xen/arch/x86/cpu/vpmu_amd.c b/xen/arch/x86/cpu/vpmu_amd.c
> index 825be72..04da81a 100644
> --- a/xen/arch/x86/cpu/vpmu_amd.c
> +++ b/xen/arch/x86/cpu/vpmu_amd.c
> @@ -438,6 +438,8 @@ static void amd_vpmu_destroy(struct vcpu *v)
>  amd_vpmu_unset_msr_bitmap(v);
>  
>  xfree(vpmu->context);
> +vpmu->context = NULL;
> +vpmu->priv_context = NULL;
>  
>  if ( vpmu_is_set(vpmu, VPMU_RUNNING) )
>  release_pmu_ownship(PMU_OWNER_HVM);
> diff --git a/xen/arch/x86/cpu/vpmu_intel.c b/xen/arch/x86/cpu/vpmu_intel.c
> index b3750d7..12f80ae 100644
> --- a/xen/arch/x86/cpu/vpmu_intel.c
> +++ b/xen/arch/x86/cpu/vpmu_intel.c
> @@ -828,7 +828,9 @@ static void core2_vpmu_destroy(struct vcpu *v)
>  struct vpmu_struct *vpmu = vcpu_vpmu(v);
>  
>  xfree(vpmu->context);
> +vpmu->context = NULL;
>  xfree(vpmu->priv_context);
> +vpmu->priv_context = NULL;
>  if ( has_hvm_container_vcpu(v) && cpu_has_vmx_msr_bitmap )
>  core2_vpmu_unset_msr_bitmap(v->arch.hvm_vmx.msr_bitmap);
>  release_pmu_ownship(PMU_OWNER_HVM);
> 

-- 
Company details: http://ts.fujitsu.com/imprint.html

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

Re: [Xen-devel] [PATCH v25 00/15] x86/PMU: Xen PMU PV(H) support

2015-07-10 Thread Dietmar Hahn 
Am Freitag 19 Juni 2015, 14:44:31 schrieb Boris Ostrovsky:
 Changes in v25:
 * Add extra check for consistency in patch 4
 * Replace few returns with 'ret = -E...' (patches 4 and 12)
 * Clarified commit message in patch 8
 * A couple of cosmetic changes in patch 12
 (I left AMD multi-counter problem unfixed since what I thought would
  be sufficient to fix it did not quite work and I don't want to do
  a partial fix)

I did some tests with HVM guests on Intel processors so for the vmx part:

Tested-by: Dietmar Hahn dietmar.h...@ts.fujitsu.com


Many Thanks!
Dietmar.

-- 
Company details: http://ts.fujitsu.com/imprint.html


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

Re: [Xen-devel] [PATCH v25 12/15] x86/VPMU: Handle PMU interrupts for PV(H) guests

2015-07-09 Thread Dietmar Hahn 
Am Freitag 19 Juni 2015, 14:44:43 schrieb 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 boris.ostrov...@oracle.com
 Acked-by: Daniel De Graaf dgde...@tycho.nsa.gov
 Acked-by: Kevin Tian kevin.t...@intel.com
 ---
 Changes in v25:
 * Replaced 'int num_enabled' with 'bool_t is_running' in amd_vpmu_load()
 * Partially restored comment in amd_vpmu_save()
 * Replaced sizeof(*ctxt) with offsetof() svm_vpmu_initialise()'s memcpy
 * Replaced a couple of returns with 'ret=-E...' in do_xenpmu_op()

Reviewed-by: Dietmar Hahn dietmar.h...@ts.fujitsu.com

 
 
  xen/arch/x86/hvm/svm/vpmu.c   |  92 ++---
  xen/arch/x86/hvm/vmx/vpmu_core2.c | 108 ++-
  xen/arch/x86/hvm/vpmu.c   | 269 
 ++
  xen/include/asm-x86/hvm/vpmu.h|  10 +-
  xen/include/public/arch-x86/pmu.h |  41 +-
  xen/include/public/pmu.h  |   2 +
  xen/include/xsm/dummy.h   |   4 +-
  xen/xsm/flask/hooks.c |   2 +
  8 files changed, 467 insertions(+), 61 deletions(-)
 
 diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
 index 934f1b7..17272cb 100644
 --- a/xen/arch/x86/hvm/svm/vpmu.c
 +++ b/xen/arch/x86/hvm/svm/vpmu.c
 @@ -46,6 +46,9 @@ static const u32 __read_mostly *counters;
  static const u32 __read_mostly *ctrls;
  static bool_t __read_mostly k7_counters_mirrored;
  
 +/* Total size of PMU registers block (copied to/from PV(H) guest) */
 +static unsigned int __read_mostly regs_sz;
 +
  #define F10H_NUM_COUNTERS   4
  #define F15H_NUM_COUNTERS   6
  #define MAX_NUM_COUNTERSF15H_NUM_COUNTERS
 @@ -158,7 +161,7 @@ static void amd_vpmu_init_regs(struct xen_pmu_amd_ctxt 
 *ctxt)
  unsigned i;
  uint64_t *ctrl_regs = vpmu_reg_pointer(ctxt, ctrls);
  
 -memset(ctxt-regs[0], 0, 2 * sizeof(uint64_t) * num_counters);
 +memset(ctxt-regs[0], 0, regs_sz);
  for ( i = 0; i  num_counters; i++ )
  ctrl_regs[i] = ctrl_rsvd[i];
  }
 @@ -211,27 +214,65 @@ 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 )
 +{
 +bool_t is_running = 0;
 +struct xen_pmu_amd_ctxt *guest_ctxt = vpmu-xenpmu_data-pmu.c.amd;
 +
 +ASSERT(!is_hvm_vcpu(v));
 +
 +ctxt = vpmu-context;
 +ctrl_regs = vpmu_reg_pointer(ctxt, ctrls);
 +
 +memcpy(ctxt-regs[0], guest_ctxt-regs[0], regs_sz);
 +
 +for ( i = 0; i  num_counters; i++ )
 +{
 +if ( (ctrl_regs[i]  CTRL_RSVD_MASK) != ctrl_rsvd[i] )
 +{
 +/*
 + * Not necessary to re-init context since we should never 
 load
 + * it until guest provides valid values. But just to be safe.
 + */
 +amd_vpmu_init_regs(ctxt);
 +return -EINVAL;
 +}
 +
 +if ( is_pmu_enabled(ctrl_regs[i]) )
 +is_running = 1;
 +}
 +
 +if ( is_running )
 +vpmu_set(vpmu, VPMU_RUNNING);
 +else
 +vpmu_reset(vpmu, VPMU_RUNNING);
  }
  
  vpmu_set(vpmu, VPMU_CONTEXT_LOADED);
  
  context_load(v);
 +
 +return 0;
  }
  
  static inline void context_save(struct vcpu *v)
 @@ -246,22 +287,18 @@ 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

Re: [Xen-devel] [PATCH v25 14/15] x86/VPMU: Add privileged PMU mode

2015-07-09 Thread Dietmar Hahn 
Am Freitag 19 Juni 2015, 14:44:45 schrieb 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 boris.ostrov...@oracle.com
 Acked-by: Jan Beulich jbeul...@suse.com

Reviewed-by: Dietmar Hahn dietmar.h...@ts.fujitsu.com

 ---
  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 9d6ca93..3ad0b94 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;
 @@ -472,7 +485,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--;
 @@ -525,7 +540,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) )
 @@ -645,12 +661,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

Re: [Xen-devel] [PATCH v25 06/15] x86/VPMU: Initialize PMU for PV(H) guests

2015-07-08 Thread Dietmar Hahn 
Am Freitag 19 Juni 2015, 14:44:37 schrieb Boris Ostrovsky:
 Code for initializing/tearing down PMU for PV guests
 
 Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com
 Acked-by: Daniel De Graaf dgde...@tycho.nsa.gov
 Acked-by: Jan Beulich jbeul...@suse.com
 Acked-by: Kevin Tian kevin.t...@intel.com

Reviewed-by: Dietmar Hahn dietmar.h...@ts.fujitsu.com

 ---
  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 45b5cb2..f553eb5 100644
 --- a/tools/flask/policy/policy/modules/xen/xen.te
 +++ b/tools/flask/policy/policy/modules/xen/xen.te
 @@ -130,6 +130,10 @@ if (guest_writeconsole) {
   dontaudit domain_type xen_t : xen writeconsole;
  }
  
 +# 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 dc18565..b699f68 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 d5e5242..83a81f5 100644
 --- a/xen/arch/x86/hvm/hvm.c
 +++ b/xen/arch/x86/hvm/hvm.c
 @@ -4931,6 +4931,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 a02f983..680eebe 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 0837627..50e11dd 100644
 --- a/xen/arch/x86/hvm/vmx/vmx.c
 +++ b/xen/arch/x86/hvm/vmx/vmx.c
 @@ -140,7 +140,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 025c970..e7642e5 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

Re: [Xen-devel] [PATCH v25 05/15] x86/VPMU: Initialize VPMUs with __initcall

2015-07-08 Thread Dietmar Hahn 
Am Freitag 19 Juni 2015, 14:44:36 schrieb Boris Ostrovsky:
 Move some VPMU initilization operations into __initcalls to avoid performing
 same tests and calculations for each vcpu.
 
 Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com
 Acked-by: Jan Beulich jbeul...@suse.com

For the Intel/VMX part:

Reviewed-by: Dietmar Hahn dietmar.h...@ts.fujitsu.com

 ---
  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 cfcdf42..025c970 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

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

2015-07-08 Thread Dietmar Hahn 
Am Freitag 19 Juni 2015, 14:44:41 schrieb Boris Ostrovsky:
 No need to compute those masks on every MSR access.
 
 Also, when checking MSR_P6_EVNTSELx registers make sure that bit 21
 (which is a reserved bit) is not set.
 
 Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com
 Acked-by: Kevin Tian kevin.t...@intel.com

Reviewed-by: Dietmar Hahn dietmar.h...@ts.fujitsu.com

 ---
  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 089154e..166277a 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 -EINVAL;
  
 @@ -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 -EINVAL;
  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 -EINVAL;
  
  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 -EINVAL;
  
  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 +
 

-- 
Company details: http://ts.fujitsu.com/imprint.html

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

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

2015-07-08 Thread Dietmar Hahn 
Am Freitag 19 Juni 2015, 14:44:39 schrieb Boris Ostrovsky:
 Hypervisor cannot easily inject faults into PV guests from arch-specific VPMU
 read/write MSR handlers (unlike it is in the case of HVM guests).
 
 With this patch vpmu_do_msr() will return an error code to indicate whether an
 error was encountered during MSR processing (instead of stating that the 
 access
 was to a VPMU register). The caller will then decide how to deal with the 
 error.
 
 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 boris.ostrov...@oracle.com
 Acked-by: Kevin Tian kevin.t...@intel.com
 ---
 Changes in v25:
 * Updated commit message to mention reason for changing vpmu_do_msr return 
 values

Reviewed-by: Dietmar Hahn dietmar.h...@ts.fujitsu.com

 
  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 | 86 
 +++
  4 files changed, 57 insertions(+), 65 deletions(-)
 
 diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
 index 680eebe..3b5d15d 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 50e11dd..db1fa82 100644
 --- a/xen/arch/x86/hvm/vmx/vmx.c
 +++ b/xen/arch/x86/hvm/vmx/vmx.c
 @@ -2166,12 +2166,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) )
 @@ -2347,7 +2352,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 )
 @@ -2375,9 +2380,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

Re: [Xen-devel] [PATCH v25 04/15] x86/VPMU: Interface for setting PMU mode and flags

2015-07-07 Thread Dietmar Hahn 
Am Freitag 19 Juni 2015, 14:44:35 schrieb 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 boris.ostrov...@oracle.com
 Acked-by: Daniel De Graaf dgde...@tycho.nsa.gov
 
 ---
 Changes in v25:
 * Added (vpmu_features == pmu_params.val) check in 
 do_xenpmu_op:XENPMU_mode_get

You mean in do_xenpmu_op:XENPMU_feature_set I think?

Reviewed-by: Dietmar Hahn dietmar.h...@ts.fujitsu.com

Dietmar.


-- 
Company details: http://ts.fujitsu.com/imprint.html

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

Re: [Xen-devel] [PATCH v25 07/15] x86/VPMU: Save VPMU state for PV guests during context switch

2015-07-07 Thread Dietmar Hahn 
Am Freitag 19 Juni 2015, 14:44:38 schrieb 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 boris.ostrov...@oracle.com
 
 ---
 Changes in v25:
 * Replaced is_hvm_vcpu with is_hvm_domain to be consistent with recent changes
  to context_switch()

Reviewed-by: Dietmar Hahn dietmar.h...@ts.fujitsu.com

 
  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 b699f68..11197e4 100644
 --- a/xen/arch/x86/domain.c
 +++ b/xen/arch/x86/domain.c
 @@ -1543,17 +1543,14 @@ void context_switch(struct vcpu *prev, struct vcpu 
 *next)
  }
  
  if ( prev != next )
 -_update_runstate_area(prev);
 -
 -if ( is_hvm_domain(prevd) )
  {
 -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_domain(prevd)  !list_empty(prev-arch.hvm_vcpu.tm_list) )
 +pt_save_timer(prev);
 +
  local_irq_disable();
  
  set_current(next);
 @@ -1591,15 +1588,16 @@ void context_switch(struct vcpu *prev, struct vcpu 
 *next)
 !is_hardware_domain(nextd));
  }
  
 -if (is_hvm_domain(nextd)  (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);
  
 

-- 
Company details: http://ts.fujitsu.com/imprint.html

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

[Xen-devel] [PATCH] VPMU: add lost Intel processor

2015-06-03 Thread Dietmar Hahn 
Hi,

it seems somewhere the Intel processor
cpu family  : 6
model   : 47
model name  : Intel(R) Xeon(R) CPU E7- 8837  @ 2.67GHz
got lost.

Dietmar.


Signed-off-by: Dietmar Hahn dietmar.h...@ts.fujitsu.com

diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c 
b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index 8ad522a..bbe6197 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -849,6 +849,7 @@ int vmx_vpmu_initialise(struct vcpu *v, unsigned int 
vpmu_flags)
 case 0x25: /* 32 nm nehalem, Clarkdale, Arrandale */
 case 0x2c: /* 32 nm nehalem, Gulftown, Westmere-EP */
 case 0x27: /* 32 nm Westmere-EX */
+case 0x2f: /* 32 nm Westmere-EX */
 
 case 0x3a: /* IvyBridge */
 case 0x3e: /* IvyBridge EP */

-- 
Company details: http://ts.fujitsu.com/imprint.html

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

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

2015-05-18 Thread Dietmar Hahn 
Am Freitag 08 Mai 2015, 17:06:11 schrieb Boris Ostrovsky:
 Add support for handling PMU interrupts for PV(H) guests.

I have only some minor nits below.

Reviewed-by: Dietmar Hahn dietmar.h...@ts.fujitsu.com

 
 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 boris.ostrov...@oracle.com
 Acked-by: Daniel De Graaf dgde...@tycho.nsa.gov
 ---
 Changes in v21:
 * Copy hypervisor-private VPMU context to shared page during interrupt and 
 copy
   it back during XENPMU_flush (see also changes to patch 6). Verify 
 user-provided
   VPMU context before loading it into hypervisor-private one (and then to HW).
   Specifically, the changes are:
   - Change definitions of save/load ops to take a flag that specifies whether
 a copy and verification is required and, for the load op, to return error
 if verification fails.
   - Both load ops: update VMPU_RUNNING flag based on user-provided context, 
 copy
 VPMU context
   - Both save ops: copy VPMU context
   - core2_vpmu_load(): add core2_vpmu_verify() call to do context verification
   - precompute VPMU context size into ctxt_sz to use in memcpy
   - Return an error in XENPMU_flush (vpmu.c) if verification fails.
 * Non-privileged domains should not be provided with physical CPUID in
   vpmu_do_interrupt(), set it to vcpu_id instead.
 
  xen/arch/x86/hvm/svm/vpmu.c   |  63 +++---
  xen/arch/x86/hvm/vmx/vpmu_core2.c |  87 --
  xen/arch/x86/hvm/vpmu.c   | 237 
 +++---
  xen/include/asm-x86/hvm/vpmu.h|   8 +-
  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, 359 insertions(+), 47 deletions(-)
 
 diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
 index 74d03a5..efe5573 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 long __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

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

2015-03-25 Thread Dietmar Hahn 
Am Dienstag 17 März 2015, 10:54:09 schrieb Boris Ostrovsky:
 The two routines share most of their logic.
 
 Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com
 ---
 Changes in v19:
 * const-ified arch_vpmu_ops in vpmu_do_wrmsr
 * non-changes:
- kept 'current' as a non-initializer to avoid unnecessary initialization
  in the (common) non-VPMU case
- kept 'nop' label since there are multiple dissimilar cases that can cause
  a non-emulation of VPMU access
 
  xen/arch/x86/hvm/vpmu.c| 76 
 +-
  xen/include/asm-x86/hvm/vpmu.h | 14 ++--
  2 files changed, 42 insertions(+), 48 deletions(-)
 
 diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
 index c287d8b..beed956 100644
 --- a/xen/arch/x86/hvm/vpmu.c
 +++ b/xen/arch/x86/hvm/vpmu.c
 @@ -103,63 +103,47 @@ 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 vcpu *curr;
  struct vpmu_struct *vpmu;
 +const struct arch_vpmu_ops *ops;

What is this const useful for in this small function?

Reviewed-by: Dietmar Hahn dietmar.h...@ts.fujitsu.com

Dietmar.

 +int ret = 0;
  
  if ( vpmu_mode == XENPMU_MODE_OFF )
 -return 0;
 +goto nop;
  
 +curr = current;
  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-xenpmu_data-pmu.pmu_flags  PMU_CACHED) )
 -{
 -vpmu_set(vpmu, VPMU_CONTEXT_SAVE);
 -vpmu-arch_vpmu_ops-arch_vpmu_save(curr);
 -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-xenpmu_data-pmu.pmu_flags  
 PMU_CACHED) )
  {
 -*msr_content = 0;
 -return 0;
 +vpmu_set(vpmu, VPMU_CONTEXT_SAVE);
 +ops-arch_vpmu_save(curr);
 +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-xenpmu_data-pmu.pmu_flags  PMU_CACHED) )
 -{
 -vpmu_set(vpmu, VPMU_CONTEXT_SAVE);
 -vpmu-arch_vpmu_ops-arch_vpmu_save(curr);
 -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 642a4b7..63851a7 100644
 --- a/xen/include/asm-x86/hvm/vpmu.h
 +++ b/xen/include/asm-x86/hvm/vpmu.h
 @@ -99,8 +99,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);
 @@ -110,6 +110,16 @@ void vpmu_save(struct vcpu *v);
  void vpmu_load(struct vcpu *v);
  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

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

2015-03-25 Thread Dietmar Hahn 
Am Mittwoch 25 März 2015, 09:29:14 schrieb Dietmar Hahn:
 Am Dienstag 17 März 2015, 10:54:09 schrieb Boris Ostrovsky:
  The two routines share most of their logic.
  
  Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com
  ---
  Changes in v19:
  * const-ified arch_vpmu_ops in vpmu_do_wrmsr
  * non-changes:
 - kept 'current' as a non-initializer to avoid unnecessary initialization
   in the (common) non-VPMU case
 - kept 'nop' label since there are multiple dissimilar cases that can 
  cause
   a non-emulation of VPMU access
  
   xen/arch/x86/hvm/vpmu.c| 76 
  +-
   xen/include/asm-x86/hvm/vpmu.h | 14 ++--
   2 files changed, 42 insertions(+), 48 deletions(-)
  
  diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
  index c287d8b..beed956 100644
  --- a/xen/arch/x86/hvm/vpmu.c
  +++ b/xen/arch/x86/hvm/vpmu.c
  @@ -103,63 +103,47 @@ 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 vcpu *curr;
   struct vpmu_struct *vpmu;
  +const struct arch_vpmu_ops *ops;
 
 What is this const useful for in this small function?

Sorry for the question and for the noise I already got it!

 
 Reviewed-by: Dietmar Hahn dietmar.h...@ts.fujitsu.com
 
 Dietmar.
 
  +int ret = 0;
   
   if ( vpmu_mode == XENPMU_MODE_OFF )
  -return 0;
  +goto nop;
   
  +curr = current;
   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-xenpmu_data-pmu.pmu_flags  PMU_CACHED) )
  -{
  -vpmu_set(vpmu, VPMU_CONTEXT_SAVE);
  -vpmu-arch_vpmu_ops-arch_vpmu_save(curr);
  -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-xenpmu_data-pmu.pmu_flags  
  PMU_CACHED) )
   {
  -*msr_content = 0;
  -return 0;
  +vpmu_set(vpmu, VPMU_CONTEXT_SAVE);
  +ops-arch_vpmu_save(curr);
  +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-xenpmu_data-pmu.pmu_flags  PMU_CACHED) )
  -{
  -vpmu_set(vpmu, VPMU_CONTEXT_SAVE);
  -vpmu-arch_vpmu_ops-arch_vpmu_save(curr);
  -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 642a4b7..63851a7 100644
  --- a/xen/include/asm-x86/hvm/vpmu.h
  +++ b/xen/include/asm-x86/hvm/vpmu.h
  @@ -99,8 +99,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);
  @@ -110,6 +110,16 @@ void vpmu_save

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

2015-03-25 Thread Dietmar Hahn 
Am Dienstag 17 März 2015, 10:54:10 schrieb 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 boris.ostrov...@oracle.com

Reviewed-by: Dietmar Hahn dietmar.h...@ts.fujitsu.com

Dietmar.

 ---
 Changes in v19:
 * Slightly different mode changing logic in xenpmu_op() since we no longer
   allow mode changes while VPMUs are active
 
  xen/arch/x86/hvm/vpmu.c  | 34 +-
  xen/arch/x86/traps.c | 13 +
  xen/include/public/pmu.h |  3 +++
  3 files changed, 41 insertions(+), 9 deletions(-)
 
 diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
 index beed956..71c5063 100644
 --- a/xen/arch/x86/hvm/vpmu.c
 +++ b/xen/arch/x86/hvm/vpmu.c
 @@ -111,7 +111,9 @@ int vpmu_do_msr(unsigned int msr, uint64_t *msr_content,
  const struct arch_vpmu_ops *ops;
  int ret = 0;
  
 -if ( vpmu_mode == XENPMU_MODE_OFF )
 +if ( (vpmu_mode == XENPMU_MODE_OFF) ||
 + ((vpmu_mode  XENPMU_MODE_ALL) 
 +  !is_hardware_domain(current-domain)) )
  goto nop;
  
  curr = current;
 @@ -166,8 +168,12 @@ void vpmu_do_interrupt(struct cpu_user_regs *regs)
  struct vcpu *sampled = current, *sampling;
  struct vpmu_struct *vpmu;
  
 -/* 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 )
 @@ -177,17 +183,18 @@ void vpmu_do_interrupt(struct cpu_user_regs *regs)
  sampling = sampled;
  
  vpmu = vcpu_vpmu(sampling);
 -if ( !is_hvm_vcpu(sampling) )
 +if ( !is_hvm_vcpu(sampling) || (vpmu_mode  XENPMU_MODE_ALL) )
  {
  /* PV(H) guest */
  const struct cpu_user_regs *cur_regs;
  uint64_t *flags = vpmu-xenpmu_data-pmu.pmu_flags;
 -uint32_t domid = DOMID_SELF;
 +uint32_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;
  
 @@ -204,6 +211,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) )
 @@ -232,7 +244,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;
 @@ -508,7 +521,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 == NULL) ||
 @@ -627,12 +641,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 1eb7bb4..8a40deb 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_PERFCTR5:
  if ( vpmu_msr || (boot_cpu_data.x86_vendor == 
 X86_VENDOR_AMD

Re: [Xen-devel] [PATCH v19 01/14] x86/VPMU: VPMU should not exist when vpmu_initialise() is called

2015-03-19 Thread Dietmar Hahn 
Am Dienstag 17 März 2015, 10:53:58 schrieb Boris Ostrovsky:
 We don't need to try to destroy it since it can't be already allocated at the
 time we try to initialize it.
 
 Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com
 Suggested-by: Andrew Cooper andrew.coop...@citrix.com

Seems to be already commited.

Dietmar.


 ---
 
 Changes in v19:
 * Removed unnecesary test for VPMU_CONTEXT_ALLOCATED in svm/vpmu.c
 
  xen/arch/x86/hvm/svm/vpmu.c | 3 ---
  xen/arch/x86/hvm/vpmu.c | 5 +
  2 files changed, 1 insertion(+), 7 deletions(-)
 
 diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
 index 64dc167..6764070 100644
 --- a/xen/arch/x86/hvm/svm/vpmu.c
 +++ b/xen/arch/x86/hvm/svm/vpmu.c
 @@ -359,9 +359,6 @@ static int amd_vpmu_initialise(struct vcpu *v)
  struct vpmu_struct *vpmu = vcpu_vpmu(v);
  uint8_t family = current_cpu_data.x86;
  
 -if ( vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
 -return 0;
 -
  if ( counters == NULL )
  {
   switch ( family )
 diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
 index 0e6b6c0..c3273ee 100644
 --- a/xen/arch/x86/hvm/vpmu.c
 +++ b/xen/arch/x86/hvm/vpmu.c
 @@ -236,10 +236,7 @@ void vpmu_initialise(struct vcpu *v)
  if ( is_pvh_vcpu(v) )
  return;
  
 -if ( vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
 -vpmu_destroy(v);
 -vpmu_clear(vpmu);
 -vpmu-context = NULL;
 +ASSERT(!vpmu-flags  !vpmu-context);
  
  switch ( vendor )
  {
 

-- 
Company details: http://ts.fujitsu.com/imprint.html

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

Re: [Xen-devel] [PATCH v19 05/14] x86/VPMU: Interface for setting PMU mode and flags

2015-03-19 Thread Dietmar Hahn 
Am Donnerstag 19 März 2015, 13:28:56 schrieb Jan Beulich:
  On 19.03.15 at 14:12, dietmar.h...@ts.fujitsu.com wrote:
  Am Dienstag 17 März 2015, 10:54:02 schrieb Boris Ostrovsky:
  +case XENPMU_feature_get:
  
  memset(pmu_params, 0, sizeof(pmu_params));  ?
  
  +pmu_params.val = vpmu_features;
  +if ( copy_field_to_guest(arg, pmu_params, val) )
  +return -EFAULT;
 
 Why? Notice the _field_ in the used function's name.
 
 Jan

Ah, yes, thanks! Sorry for noise.

Dietmar.

 



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

Re: [Xen-devel] [PATCH v19 05/14] x86/VPMU: Interface for setting PMU mode and flags

2015-03-19 Thread Dietmar Hahn 
Am Dienstag 17 März 2015, 10:54:02 schrieb 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 boris.ostrov...@oracle.com
 Acked-by: Daniel De Graaf dgde...@tycho.nsa.gov

Reviewed-by: Dietmar Hahn dietmar.h...@ts.fujitsu.com

Only two minor comments below.

 ---
 
 Changes in v19:
 * Keep track of active vpmu count and allow certain mode changes only when 
 the count
   is zero
 * Drop vpmu_unload routines
 * Revert to to using opt_vpmu_enabled
 * Changes to oprofile code are no longer needed
 * Changes to vmcs.c are no longer needed
 * Simplified vpmu_switch_from/to inlines
 
  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  | 155 
 +--
  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 |  45 
  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, 279 insertions(+), 25 deletions(-)
 
 diff --git a/tools/flask/policy/policy/modules/xen/xen.te 
 b/tools/flask/policy/policy/modules/xen/xen.te
 index c0128aa..870ff81 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 21f0766..60d9a80 100644
 --- a/xen/arch/x86/domain.c
 +++ b/xen/arch/x86/domain.c
 @@ -1536,7 +1536,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);
 @@ -1581,7 +1581,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 c2405bf..6280644 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

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

2015-03-19 Thread Dietmar Hahn 
Am Dienstag 17 März 2015, 10:53:57 schrieb Boris Ostrovsky:
 
 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

Hi,

is anybody of you working on PEBS support for x86_64?

Dietmar.

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

Re: [Xen-devel] Branch Trace Storage for guests and VPMUinitialization

2015-02-26 Thread Dietmar Hahn 
Am Mittwoch 25 Februar 2015, 11:31:31 schrieb Boris Ostrovsky:
 On 02/25/2015 10:12 AM, kevin.ma...@gdata.de wrote:
  -Ursprüngliche Nachricht-
  Von: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
  Gesendet: Dienstag, 24. Februar 2015 18:13
  An: Mayer, Kevin; xen-devel@lists.xen.org
  Betreff: Re: [Xen-devel] Branch Trace Storage for guests and VPMU
  initialization
 
  On 02/24/2015 10:27 AM, kevin.ma...@gdata.de wrote:
  Hi guys
 
  I`m trying to set up the BTS so that I can log the branches taken in
  the guest using Xen 4.4.1 with a WinXP SP3 guest on a Core i7 Sandy
  Bridge.
 
  I added the vpmu=bts boot parameter to my grub2 configuration and
  extended the libxl,libxc,domctl,… with an own command so that I can
  trigger the activation of the BTS whenever I want.
 
 
  I am not sure why you are doing all these changes to Xen code. BTS is
  supposed to be managed from the guest. For example, a Fedora HVM guest
  will produce this:
 
  [root@dhcp-burlington7-2nd-B-east-10-152-55-140 ~]# perf record -e
  branches:u -c 1 -d sleep 1 [ perf record: Woken up 3838 times to write 
  data ] [
  perf record: Captured and wrote 0.704 MB perf.data (~30756 samples) ]
  [root@dhcp-burlington7-2nd-B-east-10-152-55-140 ~]# perf script -f
  ip,addr,sym,dso,symoff --show-kernel-path
 8167c347 native_irq_return_iret+0x0 (/proc/kcore) =
  328c001590 [unknown] (/proc/kcore)
 8167c347 native_irq_return_iret+0x0 (/proc/kcore) =
  328c001590 [unknown] ([unknown])
   328c001593 [unknown] ([unknown]) =   328c004b70 [unknown]
  ([unknown])
  ...
 
  I want to be able to log the taken branches (of the guest) without the need 
  to modify the guest at all.
  This means I have to do all the logic in the hypervisor, or am I wrong?
 
 In that case, yes. But then you have to make sure that at least
   * you don't load guest's VPMU (or, at least, BTS-related registers) on 
 context switch

But you need to modify PMU registers when switching to/from the guest context
to get PMU running.
I didn't think of using the VPMU stuff with modifying the context from outside
the guest.

   * You don't send the interrupt to the guest (meaning that you will 
 need to somehow inform dom0 of the BTS interrupt)
 
 and probably more.
 
 Essentially, you want dom0 to profile the guest. I have been working on
 patches that would allow that but they are still under review.
 
 
 
  In this command I do the following:
 
  I set up the memory region for the BTS Buffer and the DS Buffer
  Management Area using xzalloc_bytes
 
 
  I don't think you should be allocating BTS buffers in the hypervisor, they 
  are
  in guest's memory.
  I agree. As I said I think this is where my main problem is at the moment.
  Is there any way I can allocate memory in the hypervisor in a way the guest 
  can access it?
 
 I am not sure this is what you want since you seem to *not* want the 
 guest to process the samples, right?
 
 But yes, you can. E.g. something like what map_vcpu_info() does. (I have 
 no idea how you'd do this from Windows.)

The DS buffer has to be mapped within the guests address space so the CPU
running in guest context can access this area. Otherwise you get this
triple fault.
So I would think you need a mixture of writing some stuff in Windows and
patching the hypervisor.

Dietmar.

 
 
  Of course the guest must not be able to use this memory in its normal 
  operations but just for BTS.
  Is this even possible? I am rather confused at the moment. :-D
 
  Then I write the pointer to the BTS Buffer into the DS Buffer
  Management Area at +0x0 and +0x8 (BTS Buffer Base and BTS Index)
 
  When I use vmx_msr_write_intercept to store the value in
  MSR_IA32_DS_AREA the host reboots (my idea is he tries to access a
  vpmu-struct that isn´t there in the current vcpu and panics).
 
 
 Who is trying to write to MSR_IA32_DS_AREA? The guest or dom0? I thought 
 you said that you want dom0 to do sampling. Or are you trying to setup 
 DS area from your guest and control it from dom0? I am somewhat confused.
 
 
  Can you post hypervisor log? (hard to say how helpful it will be without
  seeing your code changes though)
 
  Right after enabling the BTS I get a triple fault.
  hvm.c:1357:d2 Triple fault on VCPU0 - invoking HVM shutdown action 1.
 
 
 That's not host reboot, this is your guest dying.
 
 
 
  When I use a modified version of vmx_msr_write_intercept I don’t get
  any crashes as long as I don’t enable BTS and TR in the
  GUEST_IA32_DEBUGCTL (BTR works). When I enable the BTS (and TR) the
  guest crashes. I suppose he gets killed by the hypervisor for
  accessing forbidden memory.
 
  Possibly because DS area point to hypervisor memory.
 
 
  Having said all this, I am not sure how well BTS works. You did notice
  this in the hypervisor log:
 
  (XEN) **
  (XEN) ** WARNING: Emulation of BTS Feature is switched on **
  (XEN) ** Using this processor

Re: [Xen-devel] [PATCH v18 05/16] x86/VPMU: Interface for setting PMU mode and flags

2015-02-18 Thread Dietmar Hahn 
Am Montag 16 Februar 2015, 17:26:48 schrieb 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 boris.ostrov...@oracle.com
 Acked-by: Daniel De Graaf dgde...@tycho.nsa.gov
 ---
  tools/flask/policy/policy/modules/xen/xen.te |   3 +
  xen/arch/x86/domain.c|   6 +-
  xen/arch/x86/hvm/svm/vpmu.c  |  25 ++-
  xen/arch/x86/hvm/vmx/vmcs.c  |   7 +-
  xen/arch/x86/hvm/vmx/vpmu_core2.c|  27 ++-
  xen/arch/x86/hvm/vpmu.c  | 240 
 +--
  xen/arch/x86/oprofile/nmi_int.c  |   3 +-
  xen/arch/x86/x86_64/compat/entry.S   |   4 +
  xen/arch/x86/x86_64/entry.S  |   4 +
  xen/include/asm-x86/hvm/vmx/vmcs.h   |   7 +-
  xen/include/asm-x86/hvm/vpmu.h   |  33 +++-
  xen/include/public/pmu.h |  45 +
  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 +
  20 files changed, 417 insertions(+), 35 deletions(-)
 
 diff --git a/tools/flask/policy/policy/modules/xen/xen.te 
 b/tools/flask/policy/policy/modules/xen/xen.te
 index c0128aa..870ff81 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 eb8ac3a..b0e3c3d 100644
 --- a/xen/arch/x86/domain.c
 +++ b/xen/arch/x86/domain.c
 @@ -1536,7 +1536,7 @@ void context_switch(struct vcpu *prev, struct vcpu 
 *next)
  if ( is_hvm_vcpu(prev) )
  {
  if (prev != next)
 -vpmu_save(vcpu_vpmu(prev));
 +vpmu_switch_from(vcpu_vpmu(prev), vcpu_vpmu(next));
  
  if ( !list_empty(prev-arch.hvm_vcpu.tm_list) )
  pt_save_timer(prev);
 @@ -1579,9 +1579,9 @@ void context_switch(struct vcpu *prev, struct vcpu 
 *next)
 !is_hardware_domain(next-domain));
  }
  
 -if (is_hvm_vcpu(next)  (prev != next) )
 +if ( is_hvm_vcpu(next)  (prev != next) )
  /* Must be done with interrupts enabled */
 -vpmu_load(vcpu_vpmu(next));
 +vpmu_switch_to(vcpu_vpmu(prev), vcpu_vpmu(next));
  
  context_saved(prev);
  
 diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
 index 72e2561..2cfdf08 100644
 --- a/xen/arch/x86/hvm/svm/vpmu.c
 +++ b/xen/arch/x86/hvm/svm/vpmu.c
 @@ -253,6 +253,26 @@ static int amd_vpmu_save(struct vpmu_struct *vpmu)
  return 1;
  }
  
 +static void amd_vpmu_unload(struct vpmu_struct *vpmu)
 +{
 +struct vcpu *v;
 +
 +if ( vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED | VPMU_FROZEN) )
 +{
 +unsigned int i;
 +
 +for ( i = 0; i  num_counters; i++ )
 +wrmsrl(ctrls[i], 0);
 +context_save(vpmu);
 +}
 +
 +v = vpmu_vcpu(vpmu);
 +if ( has_hvm_container_vcpu(v)  is_msr_bitmap_on(vpmu) )
 +amd_vpmu_unset_msr_bitmap(v);
 +
 +vpmu_reset(vpmu, VPMU_FROZEN);
 +}
 +
  static void context_update(unsigned int msr, u64 msr_content)
  {
  unsigned int i;
 @@ -471,17 +491,18 @@ struct arch_vpmu_ops amd_vpmu_ops = {
  .arch_vpmu_destroy = amd_vpmu_destroy,
  .arch_vpmu_save = amd_vpmu_save,
  .arch_vpmu_load = amd_vpmu_load,
 +.arch_vpmu_unload = amd_vpmu_unload,
  .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 (

Re: [Xen-devel] Wrong cpupool handling

2014-11-12 Thread Dietmar Hahn 
Am Dienstag 11 November 2014, 15:21:01 schrieb Juergen Gross:
 Hi again,
 
 On 11/11/2014 01:18 PM, Dietmar Hahn wrote:
  Hi list,
 
  When creating a cpupool, starting and destroying a guest within this pool,
  then removing this pool doesn't work because of EBUSY.
 
  It seems the cause of this behavior is the commit
  bac6334b51d9bcfe57ecf4a4cb5288348fcf044a.
 
  In domain_kill() the function sched_move_domain() gets called changing the
  d-cpupool pointer to the new cpupool without incrementing/decrementing the
  counters n_dom of the new/old cpupool.
 
  This leads to decrementing the wrong  cpupool0-n_dom counter when
  cpupool_rm_domain() gets called at the end and my own cpupool can't be
  destroyed because n_dom = 1!
 
  I don't have a fast patch because I'am not enough familiar with the code
  this time but I think it should be fixed for 4.5.
 
 Please discard previous patch, try this one.

Yes this patch works.
But I think in general a better solution would be to have the changing of the
cpupool pointer in sched_move_domain() together with the increment/decrement
of the counters but I see the locking problem.
Thanks.

Dietmar.

 
 Juergen
 

-- 
Company details: http://ts.fujitsu.com/imprint.html

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

Re: [Xen-devel] Wrong cpupool handling

2014-11-12 Thread Dietmar Hahn 
Am Mittwoch 12 November 2014, 11:25:14 schrieb Juergen Gross:
 On 11/12/2014 10:53 AM, Dietmar Hahn wrote:
  Am Dienstag 11 November 2014, 15:21:01 schrieb Juergen Gross:
  Hi again,
 
  On 11/11/2014 01:18 PM, Dietmar Hahn wrote:
  Hi list,
 
  When creating a cpupool, starting and destroying a guest within this pool,
  then removing this pool doesn't work because of EBUSY.
 
  It seems the cause of this behavior is the commit
  bac6334b51d9bcfe57ecf4a4cb5288348fcf044a.
 
  In domain_kill() the function sched_move_domain() gets called changing the
  d-cpupool pointer to the new cpupool without incrementing/decrementing 
  the
  counters n_dom of the new/old cpupool.
 
  This leads to decrementing the wrong  cpupool0-n_dom counter when
  cpupool_rm_domain() gets called at the end and my own cpupool can't be
  destroyed because n_dom = 1!
 
  I don't have a fast patch because I'am not enough familiar with the code
  this time but I think it should be fixed for 4.5.
 
  Please discard previous patch, try this one.
 
  Yes this patch works.
 
 Thanks. Can I add your tested-by:?

Sorry forgot it!

Tested-by: Dietmar Hahn dietmar.h...@ts.fujitsu.com

 
  But I think in general a better solution would be to have the changing of 
  the
  cpupool pointer in sched_move_domain() together with the increment/decrement
  of the counters but I see the locking problem.
 
 The scheduler should never change cpupool owned data. The cpupool
 pointer is domain data, so changing this is okay.
 
 
 Juergen
 
 
 ___
 Xen-devel mailing list
 Xen-devel@lists.xen.org
 http://lists.xen.org/xen-devel
 

-- 
Company details: http://ts.fujitsu.com/imprint.html

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

[Xen-devel] Wrong cpupool handling

2014-11-11 Thread Dietmar Hahn 
Hi list,

When creating a cpupool, starting and destroying a guest within this pool,
then removing this pool doesn't work because of EBUSY.

It seems the cause of this behavior is the commit
bac6334b51d9bcfe57ecf4a4cb5288348fcf044a.

In domain_kill() the function sched_move_domain() gets called changing the
d-cpupool pointer to the new cpupool without incrementing/decrementing the
counters n_dom of the new/old cpupool.

This leads to decrementing the wrong  cpupool0-n_dom counter when
cpupool_rm_domain() gets called at the end and my own cpupool can't be
destroyed because n_dom = 1!

I don't have a fast patch because I'am not enough familiar with the code
this time but I think it should be fixed for 4.5.

Dietmar.


-- 
Company details: http://ts.fujitsu.com/imprint.html

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