Cache monitoring technology(CMT) and memory bandwidth
monitoring technology(MBM) are resource monitoring
part of Intel resource director technology(RDT).
This patch is introducing cache monitor(CMT) to cache and
memory bandwidth monitor(MBM) for monitoring CPU memory
bandwidth.
The host capability
Move all cache banks into one data structure, this allows
us to add other cache component, such as cache monitor.
Signed-off-by: Wang Huaqiang
---
src/conf/capabilities.c | 36 +---
src/conf/capabilities.h | 10 --
2 files changed, 25 insertions(+), 21 del
Move memory bandwidth capability nodes into one data structure,
this allows us to add a monitor for memory bandwidth.
Signed-off-by: Wang Huaqiang
---
src/conf/capabilities.c | 22 ++
src/conf/capabilities.h | 10 --
2 files changed, 18 insertions(+), 14 deletions(-)
This patch introduces the resource monitor and creates the interface
for getting host capability of resource monitor from the system resource
control file system.
The resource monitor take the role of RDT monitoring group, could be
used to monitor the resource consumption information, such as the
This series of patches introduced the x86 Cache Monitoring Technology
(CMT) to libvirt by interacting with kernel resource control (resctrl)
interface. CMT is one of the Intel(R) x86 CPU feature which belongs to
the Resource Director Technology (RDT). CMT reports the occupancy of the
last level cac
Hi John,
Sorry for replying this email so late, because I dared not to promise more
answers before
they have been verified by POC code. Sometimes I have to change the design even
we have
achieved agreement in the previous discussion if they are too many difficulties
to implement.
Anyway, I am t
On Fri, Sep 14, 2018 at 05:21:17PM -0600, Jim Fehlig wrote:
> On 8/5/18 3:48 PM, Marek Marczykowski-Górecki wrote:
> > Handle PVH domain type in both directions (xen-xl->xml, xml->xen-xl).
> > And add a test for it.
> >
> > Signed-off-by: Marek Marczykowski-Górecki
> > ---
> > Does domain_conf.c
On 8/5/18 3:48 PM, Marek Marczykowski-Górecki wrote:
Handle PVH domain type in both directions (xen-xl->xml, xml->xen-xl).
And add a test for it.
Signed-off-by: Marek Marczykowski-Górecki
---
Does domain_conf.c (virDomainDefFormatInternal) still need to silently
convert VIR_DOMAIN_OSTYPE_XEN to
On 09/13/2018 03:54 AM, Lin Ma wrote:
> When we call qemuARPGetInterfaces to get IP from the host's arp table, We
> ignore VIR_DOMAIN_NET_TYPE_ETHERNET, VIR_DOMAIN_NET_TYPE_VHOSTUSER and
> VIR_DOMAIN_NET_TYPE_DIRECT due to the host's arp table won't include the
> ip <-> mac entries about these type
On 8/5/18 3:48 PM, Marek Marczykowski-Górecki wrote:
builder="hvm" is deprecated since Xen 4.10, new syntax is type="hvm" (or
type="pv", which is default). Since the old one is still supported,
still use it when writing native config, so the config will work on
older Xen too (and will also not co
On 9/10/18 7:10 PM, Marek Marczykowski-Górecki wrote:
On Mon, Sep 10, 2018 at 04:45:50PM -0600, Jim Fehlig wrote:
On 09/10/2018 04:02 PM, Marek Marczykowski-Górecki wrote:
On Mon, Sep 10, 2018 at 03:44:33PM -0600, Jim Fehlig wrote:
On 08/05/2018 03:48 PM, Marek Marczykowski-Górecki wrote:
Sin
On 09/10/2018 05:36 AM, Michal Privoznik wrote:
> It will be desirable to run transactions more often than we
> currently do. Even if the domain we're relabeling the paths for
> does not run in a namespace. If that's the case, there is no need
> to fork() as we are already running in the right n
On 09/10/2018 05:36 AM, Michal Privoznik wrote:
> Even though the current use of the functions does not require full
> implementation with transactions (none of the callers passes a path
> somewhere under /dev), it doesn't hurt either. Moreover, in
> future patches the paradigm is going to shift
On 09/10/2018 05:36 AM, Michal Privoznik wrote:
> In the future, the transactions are not going to be optional and
> they will be run regardless of domain using namespace to collect
> list of paths to be relabeled.
>
> To make sure there won't be an API that goes behind transaction
> code back
On 09/10/2018 05:36 AM, Michal Privoznik wrote:
> Even though the current use of the function does not require full
> implementation with transactions (none of the callers pass a path
> somewhere under /dev), it doesn't hurt either. Moreover, in
> future patches the paradigm is going to shift so
The libxl_domain_config_from_json API appeared in Xen 4.5, hence
there is no need to check for its existence after changing the
minimum supported Xen version to 4.6. Remove the check and its
use in the tests.
Signed-off-by: Jim Fehlig
---
m4/virt-driver-libxl.m4| 7 ---
tests/libxlxm
On 09/13/2018 10:11 PM, wang.yechao...@zte.com.cn wrote:
> I just code review, found there may be problem.
>
> The follow statement in founction qemuProcessReconnectHelper:
>
> "if (virThreadCreate(&thread, false, qemuProcessReconnect, data) < 0) "
>
> may be failed (no one can guarantee 'virT
On 09/13/2018 07:29 AM, Wang Yechao wrote:
> numa_nodes_ptr is a global variable in libnuma.so. It is been freed
> after main thread exits. If we have many running vms, restart the
> libvirtd service continuously at intervals of a few seconds, the main
> thread may exit before qemuProcessReconne
On 9/14/18 7:14 AM, Ján Tomko wrote:
On Tue, Sep 11, 2018 at 04:38:26PM -0600, Jim Fehlig wrote:
Currently the libxl driver claims support for Xen >= 4.4, but
Xen 4.4 and 4.5 are no longer supported upstream. Let's increase
the minimum supported Xen version to 4.6 and change the defined
LIBXL_AP
On 09/13/2018 07:15 AM, Wang Yechao wrote:
> user run "firewalld-cmd --reload"
> nwfilterStateReload called in main thread
> step 1. virRWLockWrite(&updateLock)
> step 2. virNWFilterLoadAllConfigs
> step 3. virRWLockUnlock(&updateLock);
>
> lauch a vm: qemuDomainCreateXML runs in other thread
>
$SUBJ:
s/virarptable/util/
On 09/13/2018 03:54 AM, Lin Ma wrote:
> commit b00c9c39 removed the label end_of_netlink_messages and 'return
> table' statement, It causes the function virArpTableGet doesn't return
> a proper virArpTable pointer.
>
> How to reproduce:
> # virsh domiflist sles12sp3
>
On Thu, 13 Sep 2018 15:36:38 +0100
"Dr. David Alan Gilbert" wrote:
> * Igor Mammedov (imamm...@redhat.com) wrote:
> > On Tue, 11 Sep 2018 17:30:31 +0400
> > Marc-André Lureau wrote:
> >
> > > Hi
> > >
> > > On Tue, Sep 11, 2018 at 5:14 PM, Igor Mammedov
> > > wrote:
> > > > On Tue, 11 Se
On 09/13/2018 03:54 AM, Lin Ma wrote:
> When we call qemuARPGetInterfaces to get IP from the host's arp table, We
> ignore VIR_DOMAIN_NET_TYPE_ETHERNET, VIR_DOMAIN_NET_TYPE_VHOSTUSER and
s/ignore/should ignore/
> VIR_DOMAIN_NET_TYPE_DIRECT due to the host's arp table won't include the
> ip <->
On Fri, 14 Sep 2018 16:19:07 +0200
Erik Skultety wrote:
> On Fri, Sep 14, 2018 at 12:50:09PM +0200, Gerd Hoffmann wrote:
> > Hi,
> >
> > > > Also libvirt manages hotpluggability per device *class*, not per device
> > > > *instance*. So a device being hotpluggable or not depending on some
> >
On 09/06/2018 10:04 AM, Cole Robinson wrote:
On 09/06/2018 09:04 AM, Martin Kletzander wrote:
On Wed, Sep 05, 2018 at 03:37:22PM +0100, Daniel P. Berrangé wrote:
On Wed, Sep 05, 2018 at 02:01:42PM +0200, Martin Kletzander wrote:
On Wed, Sep 05, 2018 at 09:28:52AM +0100, Daniel P. Berrangé wrot
On 09/11/2018 08:59 AM, Fabiano Fidêncio wrote:
> There are still a few places using virConfGetValue(), checking for the
> specific type of the pointers and so on. However, those places are not
> going to be converted as:
> - Using virConfGetValue*() would trigger virReportError() in the current
On Fri, Sep 14, 2018 at 15:36:42 +0200, Andrea Bolognani wrote:
> On Fri, 2018-09-14 at 15:01 +0200, Jiri Denemark wrote:
> > On Fri, Sep 14, 2018 at 10:35:58 +0200, Andrea Bolognani wrote:
> > > There are a few cases in which we're not reporting the correct
> > > information through 'virsh capabil
On Fri, Sep 14, 2018 at 12:50:09PM +0200, Gerd Hoffmann wrote:
> Hi,
>
> > > Also libvirt manages hotpluggability per device *class*, not per device
> > > *instance*. So a device being hotpluggable or not depending on some
> > > device property is a problem for libvirt ...
> > >
> > > I'm open t
As discussed during "[PATCH v4 00/29] vhost-user for input & GPU"
review, let's define a common set of backend conventions to help with
management layer implementation, and interoperability.
v2:
- drop --pidfile
- add some notes about daemonizing & stdin/out/err
Cc: libvir-list@redhat.com
Cc: G
I think the subject needs to be changed, to:
"qemu: Alter logic for interface command line bandwidth warning"
On 09/11/2018 05:13 AM, Roland Schulz wrote:
> Vhostuser doesn't support bandwidth and due to backwards compatibility
> it was decided to just warn users instead of erroring out
Since
On Fri, 2018-09-14 at 15:01 +0200, Jiri Denemark wrote:
> On Fri, Sep 14, 2018 at 10:35:58 +0200, Andrea Bolognani wrote:
> > There are a few cases in which we're not reporting the correct
> > information through 'virsh capabilities', leading to applications
> > such as libguestfs attempting to lau
On Tue, Sep 11, 2018 at 04:38:26PM -0600, Jim Fehlig wrote:
Currently the libxl driver claims support for Xen >= 4.4, but
Xen 4.4 and 4.5 are no longer supported upstream. Let's increase
the minimum supported Xen version to 4.6 and change the defined
LIBXL_API_VERSION to 0x040500, which is the AP
On Fri, Sep 14, 2018 at 10:35:58 +0200, Andrea Bolognani wrote:
> There are a few cases in which we're not reporting the correct
> information through 'virsh capabilities', leading to applications
> such as libguestfs attempting to launch KVM guests on a host that
> doesn't actually support them.
>
Hi
On Fri, Sep 14, 2018 at 2:55 PM, Gerd Hoffmann wrote:
> Hi,
>
>> +* --pidfile=PATH
>> +
>> +Write the process id (PID) to the given file PATH. This is mostly
>> +useful if the backend daemonize/fork itself.
>
> Is there any reason to daemonize itself?
>
> If not: shoud we disallow it and dro
Hi,
> +* --pidfile=PATH
> +
> +Write the process id (PID) to the given file PATH. This is mostly
> +useful if the backend daemonize/fork itself.
Is there any reason to daemonize itself?
If not: shoud we disallow it and drop the --pidfile switch?
If yes: should we add a --daemonize switch then
Hi,
> > Also libvirt manages hotpluggability per device *class*, not per device
> > *instance*. So a device being hotpluggable or not depending on some
> > device property is a problem for libvirt ...
> >
> > I'm open to suggestions how to handle this better, as long as the
> > libvirt people
More specifically, everything that's tested by qemucapabilities
now goes through qemucaps2xml as well.
Ideally we'll rewrite both so that listing all test cases is
unnecessary and they get picked up automatically by listing the
contents of the input directory instead, but that's a refactor
for ano
It was already available in 1.5.0.
Moreover, we're not even formatting it on the QEMU command
line, ever: we just use it as part of some logic that decides
whether KVM support should be advertised, and as it turns out
that logic is actually buggy and dropping this capability
fixes it.
https://bug
The file being present doesn't necessarily mean anything these
days, as it's created independently of whether the kvm module
has been loaded; moreover, we're already gathering all the
information we need through QMP, so poking the filesystem at
all is entirely unnecessary.
[1] https://github.com/s
This capability is documented as having one meaning (whether
KVM is enabled by default) but is actually assigned two other
meanings over its life: whether the query-kvm QMP command is
available at first, and later on whether KVM is usable / was
used during probing.
Since the query-kvm QMP command
While qemucaps2xml has a meager two test cases to its name, we
have plenty of data from qemucapabilities which is taken from
actual QEMU binaries, covers pretty much all supported QEMU
versions and architectures and is even in the right format already!
Rewrite qemucaps2xml so that it uses qemucapa
There are a few cases in which we're not reporting the correct
information through 'virsh capabilities', leading to applications
such as libguestfs attempting to launch KVM guests on a host that
doesn't actually support them.
Our code is also more complicated than it needs to be due to
backwards c
On 09/13/2018 11:51 PM, John Ferlan wrote:
>
>
> On 09/13/2018 10:09 AM, John Ferlan wrote:
>>
>>
>> On 09/13/2018 03:39 AM, Marc-André Lureau wrote:
>>> Hi
>>>
>>> On Thu, Sep 13, 2018 at 2:25 AM, John Ferlan wrote:
[...]
>>
>> So all that's "left":
>>
>> 1. "Add
Signed-off-by: Martin Kletzander
---
Pushed under the build-breaker rule.
src/util/virutil.c | 12
1 file changed, 12 insertions(+)
diff --git a/src/util/virutil.c b/src/util/virutil.c
index 3d1b02eceb31..b0334edb36a0 100644
--- a/src/util/virutil.c
+++ b/src/util/virutil.c
@@ -124
44 matches
Mail list logo
