Re: [libvirt] [PATCH] news: Add support for guest CPU configuration on s390

[Andrea Bolognani]

On Fri, 2017-01-13 at 17:25 +0100, Jiri Denemark wrote:
> Signed-off-by: Jiri Denemark 
> ---
>  docs/news.xml | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/docs/news.xml b/docs/news.xml
> index 50c3b3ea2..a076836ed 100644
> --- a/docs/news.xml
> +++ b/docs/news.xml
> @@ -73,6 +73,11 @@
>volumes when building a new logical pool on target volume(s).
>  
>
> +  
> +
> +  qemu: Add support for guest CPU configuration on s390(x)
> +
> +  
>  
>  
>

ACK and safe for freeze.

-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] How to generate better API documentation?

[Michal Privoznik]

Dear list,

now that we more or less agreed to use some new features (i.e. automatic free() 
when a variable goes out of the scope [1]), and with our NEWS efforts, do you 
think it is finally the right time to fix generation of our API docs too?

What I mean? Look here: [2] People use '@variable' notation hoping that the 
generator will put a link there. Or that our generator would allow us to:

typedef enum {
 A = X,
 B = Y,
 C = Z,
# ifdef VIR_ENUM_SENTINELS
 VIR_ENUM_LAST
# endif
} virEnum;

where X, Y, Z come from another enum.

Long story short, our documentation generator has a lot of bugs. What if 
instead of putting our effort in fixing it we would switch to something that is 
already available on the market? gtk-doc, doxygen, etc. Personally, I don't 
have any preference. Just want to know what your opinion is.
Again, if I get a green light I can put it onto the list of GSoC projects [3].

Michal


1: https://www.redhat.com/archives/libvir-list/2017-January/msg00323.html
2: 
http://libvirt.org/html/libvirt-libvirt-domain.html#virConnectDomainEventBlockJobCallback
3: http://wiki.libvirt.org/page/Google_Summer_of_Code_2017

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 1/2] perf: Compute cache_l1d config value correctly

[Nitesh Konkar]

Hello,

My earlier patch with commit id : ae16c95f1bb5591c27676c5de8d383e5612c3568
(Link:
https://www.redhat.com/archives/libvir-list/2017-January/msg00226.html )
computed the .attrConfig value incorrectly. The right way to  compute
.attrConfig value for a PERF_TYPE_HW_CACHE event is listed here (
https://linux.die.net/man/2/perf_event_open) . I somehow missed this info
at the time of sending the patch and have sent another patch to rectify it.

Link: https://www.redhat.com/archives/libvir-list/2017-January/msg00679.html

I think this patch needs to be in before 3.0.0 is released else a wrong
value shall be displayed on enabling and displaying cache_l1d perf event.

Thanks,
Nitesh Konkar.


On Sat, Jan 14, 2017 at 1:49 PM, Nitesh Konkar <
niteshkonkar.libv...@gmail.com> wrote:

> This patch computes the .attrConfig value for
> cache_l1d correctly and updates the documentation.
> The cache_l1d perf event now is renamed as
> cache_l1dra perf event for measuring read accesses
> for level 1 data cache
>
> Signed-off-by: Nitesh Konkar 
> ---
>  docs/formatdomain.html.in   | 12 ++--
>  docs/news.xml   |  5 +++--
>  docs/schemas/domaincommon.rng   |  2 +-
>  include/libvirt/libvirt-domain.h| 12 ++--
>  src/libvirt-domain.c|  5 +++--
>  src/qemu/qemu_driver.c  |  2 +-
>  src/util/virperf.c  |  8 +---
>  src/util/virperf.h  |  2 +-
>  tests/genericxml2xmlindata/generic-perf.xml |  2 +-
>  tools/virsh.pod |  6 +++---
>  10 files changed, 30 insertions(+), 26 deletions(-)
>
> diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
> index 30cb196..a8ee2db 100644
> --- a/docs/formatdomain.html.in
> +++ b/docs/formatdomain.html.in
> @@ -1937,7 +1937,7 @@
>event name='stalled_cycles_frontend' enabled='no'/
>event name='stalled_cycles_backend' enabled='no'/
>event name='ref_cpu_cycles' enabled='no'/
> -  event name='cache_l1d' enabled='no'/
> +  event name='cache_l1dra' enabled='no'/
>  /perf
>  ...
>  
> @@ -2013,14 +2013,14 @@
>  
>ref_cpu_cycles
>the count of total cpu cycles not affected by CPU frequency
> scaling
> - by applications running on the platform
> +  by applications running on the platform
>perf.ref_cpu_cycles
>  
>  
> -  cache_l1d
> -  the count of total level 1 data cache by applications running on
> -   the platform
> -  perf.cache_l1d
> +  cache_l1dra
> +  the count of total read accesses for level 1 data cache by
> +  applications running on the platform
> +  perf.cache_l1dra
>  
>
>
> diff --git a/docs/news.xml b/docs/news.xml
> index baafcff..93ab40c 100644
> --- a/docs/news.xml
> +++ b/docs/news.xml
> @@ -82,8 +82,9 @@
>  
>Add support to get the count of branch instructions
>executed, branch misses, bus cycles, stalled frontend
> -  cpu cycles, stalled backend cpu cycles, and ref cpu
> -  cycles by applications running on the platform.
> +  cpu cycles, stalled backend cpu cycles, ref cpu
> +  cycles and cache l1dra by applications running on the
> +  platform.
>  
>
>
> diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng
> index be0a609..a65ad13 100644
> --- a/docs/schemas/domaincommon.rng
> +++ b/docs/schemas/domaincommon.rng
> @@ -433,7 +433,7 @@
>stalled_cycles_frontend
>stalled_cycles_backend
>ref_cpu_cycles
> -  cache_l1d
> +  cache_l1dra
>  
>
>
> diff --git a/include/libvirt/libvirt-domain.h b/include/libvirt/libvirt-
> domain.h
> index 1e0e74c..3da0e9b 100644
> --- a/include/libvirt/libvirt-domain.h
> +++ b/include/libvirt/libvirt-domain.h
> @@ -2189,15 +2189,15 @@ void 
> virDomainStatsRecordListFree(virDomainStatsRecordPtr
> *stats);
>  # define VIR_PERF_PARAM_REF_CPU_CYCLES "ref_cpu_cycles"
>
>  /**
> - * VIR_PERF_PARAM_CACHE_L1D:
> + * VIR_PERF_PARAM_CACHE_L1DRA:
>   *
> - * Macro for typed parameter name that represents cache_l1d
> + * Macro for typed parameter name that represents cache_l1dra
>   * perf event which can be used to measure the count of total
> - * level 1 data cache by applications running on the platform.
> - * It corresponds to the "perf.cache_l1d" field in the
> - * *Stats APIs.
> + * read accesses for level 1 data cache by applications running
> + * on the platform. It corresponds to the "perf.cache_l1dra"
> + * field in the *Stats APIs.
>   */
> -# define VIR_PERF_PARAM_CACHE_L1D "cache_l1d"
> +# define VIR_PERF_PARAM_CACHE_L1DRA "cache_l1dra"
>
>  int virDomainGetPerfEvents(virDomainPtr dom,
> virTypedParameterPtr *params,
> diff --git 

Re: [libvirt] [V4] RFC for support cache tune(CAT) in libvirt

[Eli Qiao]

hi Daniel

thanks for your comments, I'll try to refine my current code to match as
this version RFC.

Eli.

2017-01-13 17:41 GMT+08:00 Daniel P. Berrange :

> On Fri, Jan 13, 2017 at 09:38:44AM +0800, 乔立勇(Eli Qiao) wrote:
> >
> > virsh capabilities
> >
> >
> >
> > 
> >
> >cpus="0,1,2,6,7,8"/>
> >  <- level 3 cache is per socket, so group them by
> > socket id
> >
> >
> >
> >> cpus="3,4,5,9,10,11"/>
> >
> >   
> >
> >   
> >
> >   
> >
> >   
> >
> >   
> >
> > ...
> >
> >  
> >
> >
> >
> > Opens
> >
> > 1.  how about add socket id to bank for bank type = l3 ?
>
> This isn't needed - with the 'cpu' IDs here, the application can
> look at the topology info in the capabilities to find out what
> socket the logical CPU is part of.
>
> > 2.  do we really want to expose l2/l3 cache for now , they are per
> core
> > resource and linux kernel don't support l2 yet (depend no hardware)?
>
> We dont't need to report all levels of cache - we just need the XML
> schema to allow it by design.
>
> > 3.  if enable CDP in resctrl, for bank type=l3 , it will be split to
> > l3data l3code, should expose this ability.
> >
> >   
> >  <- level 3 cache is per socket, so group them by
> > socket id
> >
> >
>
> 'cdp' is intel specific terminology. We need to use some more generic
> description. Perhaps we want this when CDP is enabled:
>
> 
> 


> and when its disabled just
>
> 
>
> If we have this scope option, then we'll need it when reporting too...
>
> > ## Provide a new API to get the avail cache on each bank, such as the
> > output are:
> >
> >
> >
> >id=0
> >
> >type=l3
>
> ...eg
>
>   scope=data
>
> >avail=56320
>
>
> >
> >total = ?? <- do we need this?
>
> That info is static and available from capabilities, so we
> don't need to repeat it here IMHO.
>
> >
> >
> >
> >id=1
> >
> >type=l3
> >
> >avail=56320
> >
> >
> >
> >id=3
> >
> >type=l2
> >
> >avail=256
> >
> >
> >
> > Opens:
> >
> > · Don't expose the avail cache information if the host can not do
> > the allocation of that type cache(eg, for l2 currently) ?
>
> This api should only report info about cache banks that support
> allocation/.
>
> > · We can not make all of the cache , the reservation amount is
> the
> > min_cbm_len (=1) * min_unit .
>
> If there is some minimum amount which is reserved and cannot be
> allocated, we should report that in the capabilities XML too.
> eg
>
> 
>
> > · do we need to expose total?
>
> No, that's available in capabilities XML
>
> > ##  enable CAT for a domain
> >
> >
> >
> > 1 Domain XML changes
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >

>
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > 2. Extend cputune command ?
>
> Do we need the ability to change cache allocation for a running
> guest ?  If so, then we need to extend cputune command, if not
> we can ignore it.
>
> > Opens:
> >
> >
> >
> > 1. Do we accept to extend existed API ? or using new API/virsh?
> >
> > 2. How to calculate cache size -> CBM bit?
> >
> >
> >
> > eg:
> >
> > 5632/ 2816 = 2 bits
> >
> > 5733/ 2816 = 2 bits or 3 bits?
>
> In the capabilities XML we report the min unit granularity:
>
> 
>
> So in the XML, we should report an error if the requested
> size is *not* a multiple of the reported unit granulirty
>
> > ## Restriction for using cache tune on multiple sockets' host.
> >
> >
> >
> > The l3 cache is per socket resource, kernel need to know about what's
> > affinity looks like, so for a VM which running on a multiple socket's
> host,
> > it should have NUMA setting or vcpuset pin setting. Or cache tune will
> fail.
>
> Yep, we need to report an error if cache allocation is requested
> without CPU pinning being requested for the VM.
>
>
> Regards,
> Daniel
> --
> |: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/
> :|
> |: http://libvirt.org  -o- http://virt-manager.org
> :|
> |: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/
> :|
>



-- 
Best regards
- Eli

天涯无处不重逢
a leaf duckweed belongs to the sea , where not to meet in life
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list