On 2018.10.08 03:19:25 +, Tian, Kevin wrote:
> Hi, Zhenyu,
>
> curious about the progress of this series. Is there still some open remaining
> or a new version coming soon?
>
I had new version almost ready before my vacation, planned to send after be
back.
So will refresh this later. Sorry
Hi, Zhenyu,
curious about the progress of this series. Is there still some open remaining
or a new version coming soon?
Thanks
Kevin
> From: Zhenyu Wang [mailto:zhen...@linux.intel.com]
> Sent: Friday, July 20, 2018 10:19 AM
>
> Current mdev device create interface depends on fixed mdev type,
This is a respin of my old PVHv1 patch[1], converted to PVHv2. The actual code
use "PVH" name.
The guest ostype reuse VIR_DOMAIN_OSTYPE_XEN, but to request PVH machine,
machine="xenpvh" attribute is used.
Since PVHv2 relies on features in newer Xen versions, I needed to convert also
some older
Make it easier to share HVM and PVH code where relevant. No functional
change.
Signed-off-by: Marek Marczykowski-Górecki
---
src/libxl/libxl_conf.c | 26 ++
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c
Signed-off-by: Marek Marczykowski-Górecki
---
Changes in v3:
- update for modified "libxl: add support for PVH"
- skip PVH test on too old Xen
---
tests/libxlxml2domconfigdata/basic-pvh.json | 49 ++-
tests/libxlxml2domconfigdata/basic-pvh.xml | 28 +-
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
---
Changes in v3:
- update for modified "libxl: add support for PVH"
---
src/xenconfig/xen_common.c | 11 +--
src/xenconfig/xen_xl.c
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 complicate tests).
Signed-off-by: Marek
Since this is something between PV and HVM, it makes sense to put the
setting in place where domain type is specified.
To enable it, use It is
also included in capabilities.xml, for every supported HVM guest type - it
doesn't seems to be any other requirement (besides new enough Xen).
Add a capability check for IOThread polling (all were added at the
same time, so only one check is necessary).
Based on code originally posted by Pavel Hrdina
with the only changes to include the more recent QEMU releases.
Signed-off-by: John Ferlan
---
src/qemu/qemu_capabilities.c
Add a command to allow for setting various dynamic IOThread polling
interval scope (poll-max-ns, poll-grow, and poll-shrink). Describe
the values in the virsh.pod in as generic terms as possible. The
more specific QEMU algorithm has been divulged in the previous patch.
Based heavily on code
Rather than passing an iothread_id, let's pass a qemuMonitorIOThreadInfo
structure so that a subsequent change to modify the iothread info can
just generate and pass one.
Signed-off-by: John Ferlan
---
src/qemu/qemu_driver.c | 26 +++---
1 file changed, 15 insertions(+), 11
https://bugzilla.redhat.com/show_bug.cgi?id=1545732
Implement the QEMU driver mechanism in order to set the polling
parameters for an IOThread within the bounds specified by the
QEMU qapi parameter passing.
Based heavily on patches originally posted by Pavel Hrdina
, but modified to only handle
Add an --iothread qualifier to domstats and an explanation in
the man page. Describe the values in as generic terms as possible
allowing each hypervisor to provide a specific algorithm to utilize
the values as it sees fit.
Signed-off-by: John Ferlan
---
tools/virsh-domain-monitor.c | 7 +++
Create a new API that will allow an adjustment of IOThread
polling parameters for the specified IOThread. These parameters
will not be saved in the guest XML. Currently the only parameters
supported will allow the hypervisor to adjust the parameters used
to limit and alter the scope of the polling
Separate out the fetch of the IOThread monitor call into a separate
helper so that a subsequent domain statistics change can fetch the raw
IOThread data and parse it as it sees fit.
Signed-off-by: John Ferlan
---
src/qemu/qemu_driver.c | 59 --
1 file
If there are IOThread polling values in the query-iothreads return
buffer, then fill them in and set a bool indicating their presence.
This will allow for displaying in a domain stats output eventually.
Note that the QEMU values are managed a bit differently (as int's
stored in int64_t's) than we
We're about to add a new state "modify" and thus the function
goes from just Add/Del. Use an enum to manage.
Extracted from code originally posted by Pavel Hrdina
, but placed into a separate patch.
Signed-off-by: John Ferlan
---
src/qemu/qemu_driver.c | 32 +---
1
Add functions to set the IOThreadInfo param data for the live guest.
Based on code originally posted by Pavel Hrdina ,
but extracted into a separate patch. Note that qapi expects to receive
integer parameters rather than unsigned long long or unsigned int's.
QEMU does save the value in larger
Process the IOThreads polling stats if available. Generate the
output params record to be returned to the caller with the three
values - poll-max-ns, poll-grow, and poll-shrink.
Signed-off-by: John Ferlan
---
include/libvirt/libvirt-domain.h | 1 +
src/libvirt-domain.c | 38
This series attempts to resurrect the concept of being able to modify
the IOThread polling parameters; however, in a slightly different
manner than the previous series posted by posted by Pavel Hrdina
:
https://www.redhat.com/archives/libvir-list/2017-February/msg01047.html
The work is
20 matches
Mail list logo