On 6/2/22, 11:28 AM, "Yang, Lin A" wrote:
> On 6/1/22, 11:37 PM, "Michal Prívozník" wrote:
> > Worst case scenario we can do a version check. It's very suboptimal
> > because if somebody backports your patches in QEMU, libvirt will stop
> > working despite having the version check.
> >
> > Theref
On 5/30/22, 6:09 AM, "Michal Prívozník" wrote:
> On 5/18/22 09:59, Haibin Huang wrote:
> > From: Lin Yang
> >
> > According to the result parsing from xml, add the argument of
> > SGX EPC memory backend into QEMU command line:
> >
> > #qemu-system-x86_64 \
> > .. \
> > -o
On 6/1/22, 11:37 PM, "Michal Prívozník" wrote:
> Worst case scenario we can do a version check. It's very suboptimal
> because if somebody backports your patches in QEMU, libvirt will stop
> working despite having the version check.
>
> Therefore, I'm more inclined to just use the newest API and
...
> Well, the worse news is that we cannot run a CI job to prune the artifacts
> automatically, because one would need a personal access token for that. Why
> personal access token? Because Project/Group access tokens are apparently
> unavailable on GitLab SaaS if you're not a paying customer (wh
On Thu, Jun 02, 2022 at 15:14:25 +0200, Michal Privoznik wrote:
> Obtaining a screenshot via virDomainScreenshot() works like this:
> 1) we create a temp file, label it, then
> 2) tell QEMU to store the screenshot into it, and
> 3) finally, open the file for transfer via virStream
>
> Since
On Thu, Jun 02, 2022 at 03:20:17PM +0200, Peter Krempa wrote:
> On Thu, Jun 02, 2022 at 15:02:24 +0200, Erik Skultety wrote:
> > With GitLab cutting down on shared resource usage it's very likely that
> > following our measure to decrease the number of CI minutes we'll also
> > need to decrease our
On 6/2/22 10:08, Peter Krempa wrote:
> On Thu, Jun 02, 2022 at 09:17:57 +0200, Michal Privoznik wrote:
>> At least in case of QEMU an IOThread is actually a pool of
>> threads (see iothread_set_aio_context_params() in QEMU's code
>> base). As such, it can have minimal and maximal number of worker
>
On Thu, Jun 02, 2022 at 15:02:24 +0200, Erik Skultety wrote:
> With GitLab cutting down on shared resource usage it's very likely that
> following our measure to decrease the number of CI minutes we'll also
> need to decrease our usage of storage. Start by decreasing artifact
> expiration time to 1
Obtaining a screenshot via virDomainScreenshot() works like this:
1) we create a temp file, label it, then
2) tell QEMU to store the screenshot into it, and
3) finally, open the file for transfer via virStream
Since the file is just temporary and even explicitly unlinked at
the end, no secla
With GitLab cutting down on shared resource usage it's very likely that
following our measure to decrease the number of CI minutes we'll also
need to decrease our usage of storage. Start by decreasing artifact
expiration time to 1 day for jobs that are currently exceeding it (by a
lot -> 30 days).
On Thu, Jun 02, 2022 at 09:18:04 +0200, Michal Privoznik wrote:
> As of v7.0.0-877-g70ac26b9e5 QEMU exposes its main event loop as
> an QMP object. In the very next commit (v7.0.0-878-g71ad4713cc)
> it was extended for thread-pool-min and thread-pool-max
> attributes. Expose them under new element
On 17/05/22 8:55 pm, Peter Krempa wrote:
On Mon, May 16, 2022 at 16:03:21 +0530, Rohit Kumar wrote:
Ping.
Hi Peter,
can you please take a look on this v3 patchset ?
Yes, don't worry and please be patient. There are some intricacies that
are not properly handled by your series and rather than
On 17/05/22 8:55 pm, Peter Krempa wrote:
On Mon, May 16, 2022 at 16:03:21 +0530, Rohit Kumar wrote:
Ping.
Hi Peter,
can you please take a look on this v3 patchset ?
Yes, don't worry and please be patient. There are some intricacies that
are not properly handled by your series and rather than
On Thu, Jun 02, 2022 at 09:18:03 +0200, Michal Privoznik wrote:
> Since virsh implements a wrapper over virDomainSetIOThreadParams()
> (command iothreadset) let's wire up new typed parameters there too.
>
> Signed-off-by: Michal Privoznik
> ---
> docs/manpages/virsh.rst | 7 ++-
> tools/vir
On Thu, Jun 02, 2022 at 10:15:41 +0200, Peter Krempa wrote:
> On Thu, Jun 02, 2022 at 09:18:01 +0200, Michal Privoznik wrote:
> > Our public API offers virDomainSetIOThreadParams() function which
> > allows users to set various aspects of IOThreads. Introduce two
> > new typed parameters: VIR_DOMAI
On Thu, Jun 02, 2022 at 09:18:02 +0200, Michal Privoznik wrote:
> Introduced in previous commit, QEMU driver needs to be taught how
> to set VIR_DOMAIN_IOTHREAD_THREAD_POOL_MIN and
> VIR_DOMAIN_IOTHREAD_THREAD_POOL_MAX parameters on given IOThread.
> Fortunately, this is fairly trivial to do and si
On Thu, Jun 02, 2022 at 09:18:02 +0200, Michal Privoznik wrote:
> Introduced in previous commit, QEMU driver needs to be taught how
> to set VIR_DOMAIN_IOTHREAD_THREAD_POOL_MIN and
> VIR_DOMAIN_IOTHREAD_THREAD_POOL_MAX parameters on given IOThread.
> Fortunately, this is fairly trivial to do and si
On Thu, Jun 02, 2022 at 09:18:01 +0200, Michal Privoznik wrote:
> Our public API offers virDomainSetIOThreadParams() function which
> allows users to set various aspects of IOThreads. Introduce two
> new typed parameters: VIR_DOMAIN_IOTHREAD_THREAD_POOL_MIN and
> VIR_DOMAIN_IOTHREAD_THREAD_POOL_MAX
On Thu, Jun 02, 2022 at 09:18:00 +0200, Michal Privoznik wrote:
> Signed-off-by: Michal Privoznik
> ---
> src/qemu/qemu_command.c | 15 ++-
> ...othreads-ids-pool-sizes.x86_64-latest.args | 44 +++
> tests/qemuxml2argvtest.c | 1 +
>
On Thu, Jun 02, 2022 at 09:17:59 +0200, Michal Privoznik wrote:
> Now that we have a capability that reflects whether QEMU is
> capable of setting iothread pool size, let's introduce a
> validator check to make sure users are not trying to use this
> feature with QEMU that doesn't support it.
>
>
On Thu, Jun 02, 2022 at 09:17:58 +0200, Michal Privoznik wrote:
> This capability reflects whether QEMU allows setting
> thread-pool-min and thread-pool-max attributes on iothread
> object. Since both attributes were introduced in the same commit
> (v7.0.0-878-g71ad4713cc) and can't exist independe
On Thu, Jun 02, 2022 at 09:17:57 +0200, Michal Privoznik wrote:
> At least in case of QEMU an IOThread is actually a pool of
> threads (see iothread_set_aio_context_params() in QEMU's code
> base). As such, it can have minimal and maximal number of worker
> threads. Allow setting them in domain XML
On Thu, Jun 02, 2022 at 09:17:56 +0200, Michal Privoznik wrote:
> So far, iothread configuration structure (virDomainIOThreadIDDef)
> is allocated by plain g_new0(). This is perfectly okay because
> all members of the struct default to value 0 anyway. But soon
> this is going to change. Therefore,
On Thu, Jun 02, 2022 at 09:17:55 +0200, Michal Privoznik wrote:
> Formatting iothreads is currently open coded inside of
> virDomainDefFormatInternalSetRootName(). While this works, it
> makes the function needlessly long, especially if the formatting
> code will expand in near future. Therefore, m
On Thu, Jun 02, 2022 at 09:17:54 +0200, Michal Privoznik wrote:
> In virDomainIOThreadIDDefArrayInit() the variable @iothrid is
> used only inside a loop but is declared for whole function. Bring
> the variable into the loop so that it's obvious that the variable
> is not used elsewhere.
>
> Signe
On Thu, Jun 02, 2022 at 09:17:53 +0200, Michal Privoznik wrote:
> Using g_autoptr() for @iothrid variable inside
> virDomainDefParseIOThreads() allows us to drop explicit call to
> virDomainIOThreadIDDefFree() in one case.
>
> Signed-off-by: Michal Privoznik
> ---
> src/conf/domain_conf.c | 6 ++
On Thu, Jun 02, 2022 at 09:48:28 +0200, Jiri Denemark wrote:
> On Thu, Jun 02, 2022 at 09:45:16 +0200, Peter Krempa wrote:
> > Similarly to the 'k' modifier for integers introduce 'K' for long
> > integers.
> >
> > Signed-off-by: Peter Krempa
> > ---
> > src/util/virjson.c | 5 +
> > 1 file
On Thu, Jun 02, 2022 at 09:45:16 +0200, Peter Krempa wrote:
> Similarly to the 'k' modifier for integers introduce 'K' for long
> integers.
>
> Signed-off-by: Peter Krempa
> ---
> src/util/virjson.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/src/util/virjson.c b/src/util/virj
On Thu, Jun 02, 2022 at 09:17:52 +0200, Michal Privoznik wrote:
> So far, we have functions that parse an enum, int, tristate bool,
> and what not but we have none for long long. Heavily inspired by
> virXMLPropInt(), introduce virXMLPropLongLong() for parsing long
> long attributes.
>
> Signed-of
Similarly to the 'k' modifier for integers introduce 'K' for long
integers.
Signed-off-by: Peter Krempa
---
src/util/virjson.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/util/virjson.c b/src/util/virjson.c
index 6e13e97e15..ae970c7653 100644
--- a/src/util/virjson.c
+++ b/src/u
On Thu, Jun 02, 2022 at 09:17:51 +0200, Michal Privoznik wrote:
> For easier attribute parsing we have virXMLProp*() family of
> functions. These accept flags through which a caller can pose
> some conditions onto the attribute value, for instance:
> VIR_XML_PROP_NONZERO when the attribute may not
As of v7.0.0-877-g70ac26b9e5 QEMU exposes its main event loop as
an QMP object. In the very next commit (v7.0.0-878-g71ad4713cc)
it was extended for thread-pool-min and thread-pool-max
attributes. Expose them under new element.
Signed-off-by: Michal Privoznik
---
docs/formatdomain.rst
This capability reflects whether QEMU allows setting
thread-pool-min and thread-pool-max attributes on iothread
object. Since both attributes were introduced in the same commit
(v7.0.0-878-g71ad4713cc) and can't exist independently of each
other we can stick with one capability covering both of the
Our public API offers virDomainSetIOThreadParams() function which
allows users to set various aspects of IOThreads. Introduce two
new typed parameters: VIR_DOMAIN_IOTHREAD_THREAD_POOL_MIN and
VIR_DOMAIN_IOTHREAD_THREAD_POOL_MAX which will allow users to
modify the thread-pool-min and thread-pool-ma
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2059511
Signed-off-by: Michal Privoznik
---
src/qemu/qemu_command.c | 33 +++
...othreads-ids-pool-sizes.x86_64-latest.args | 1 +
2 files changed, 34 insertions(+)
diff --git a/src/qemu/qemu_command.c b
Since the main-loop and iothread classes are derived from the
same class (EventLoopBaseClass) we don't need new capability and
can use QEMU_CAPS_IOTHREAD_THREAD_POOL_MAX directly to check
whether QEMU's capable of setting worker pool size.
Signed-off-by: Michal Privoznik
---
src/qemu/qemu_valida
Since virsh implements a wrapper over virDomainSetIOThreadParams()
(command iothreadset) let's wire up new typed parameters there too.
Signed-off-by: Michal Privoznik
---
docs/manpages/virsh.rst | 7 ++-
tools/virsh-domain.c| 24 +++-
2 files changed, 29 insertions(+
Introduced in previous commit, QEMU driver needs to be taught how
to set VIR_DOMAIN_IOTHREAD_THREAD_POOL_MIN and
VIR_DOMAIN_IOTHREAD_THREAD_POOL_MAX parameters on given IOThread.
Fortunately, this is fairly trivial to do and since these two
parameters are exposed in domain XML too the update of ina
Signed-off-by: Michal Privoznik
---
src/qemu/qemu_command.c | 15 ++-
...othreads-ids-pool-sizes.x86_64-latest.args | 44 +++
tests/qemuxml2argvtest.c | 1 +
3 files changed, 59 insertions(+), 1 deletion(-)
create mode 100644
tests
Now that we have a capability that reflects whether QEMU is
capable of setting iothread pool size, let's introduce a
validator check to make sure users are not trying to use this
feature with QEMU that doesn't support it.
Signed-off-by: Michal Privoznik
---
src/qemu/qemu_validate.c | 24
In virDomainIOThreadIDDefArrayInit() the variable @iothrid is
used only inside a loop but is declared for whole function. Bring
the variable into the loop so that it's obvious that the variable
is not used elsewhere.
Signed-off-by: Michal Privoznik
---
src/conf/domain_conf.c | 5 +++--
1 file ch
So far, iothread configuration structure (virDomainIOThreadIDDef)
is allocated by plain g_new0(). This is perfectly okay because
all members of the struct default to value 0 anyway. But soon
this is going to change. Therefore, replace those g_new0() with a
function so that the default value can be
Using g_autoptr() for @iothrid variable inside
virDomainDefParseIOThreads() allows us to drop explicit call to
virDomainIOThreadIDDefFree() in one case.
Signed-off-by: Michal Privoznik
---
src/conf/domain_conf.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/conf/d
At least in case of QEMU an IOThread is actually a pool of
threads (see iothread_set_aio_context_params() in QEMU's code
base). As such, it can have minimal and maximal number of worker
threads. Allow setting them in domain XML.
Signed-off-by: Michal Privoznik
---
docs/formatdomain.rst
Formatting iothreads is currently open coded inside of
virDomainDefFormatInternalSetRootName(). While this works, it
makes the function needlessly long, especially if the formatting
code will expand in near future. Therefore, move it into a
separate function. At the same time, make
virDomainDefIoth
For easier attribute parsing we have virXMLProp*() family of
functions. These accept flags through which a caller can pose
some conditions onto the attribute value, for instance:
VIR_XML_PROP_NONZERO when the attribute may not be zero, etc.
What we are missing is VIR_XML_PROP_NONNEGATIVE when the
So far, we have functions that parse an enum, int, tristate bool,
and what not but we have none for long long. Heavily inspired by
virXMLPropInt(), introduce virXMLPropLongLong() for parsing long
long attributes.
Signed-off-by: Michal Privoznik
---
src/libvirt_private.syms | 1 +
src/util/virxm
QEMU introduced a way to set minimal and maximal number of worker
threads for its worker thread pools. Currently, only IOThreads and main
loop pools have this ability. Nevertheless, setting these boundaries
(and basically making QEMU spawn enough threads upfront) is crucial for
real-time workloads
48 matches
Mail list logo
