8:20 a.m.
There have been a few requests [1][2] to support Xen's max_grant_frames setting
in libvirt domXML, but I'm not quite sure how to model it. The documentation [3]
on this setting states:
Specify the maximum number of grant frames the domain is allowed to have. This
value controls how many pages the domain is able to grant access to for other
domains, needed e.g. for the operation of paravirtualized devices. The default
is settable via xl.conf(5).
It smells of a <memtune> setting, e.g. the amount of memory a domain can share,
but doesn't map to any of the existing settings. A new subelement <shared_limit>
doesn't feel right. Does anyone suggest a better way of modeling max_grant_frames?
Another option I considered is setting the value based on number of PV devices,
but I think that flies in the face of libvirt's policy of not dictating policy.
Regardless of domain config modeling I can work on a driver-wide setting in
libxl.conf, similar to Xen's xl.conf(5) global.
Regards,
Jim
[1] https://www.redhat.com/archives/libvir-list/2018-April/msg00216.html
[2] https://www.redhat.com/archives/libvirt-users/2019-January/msg00011.html
[3]
http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/man/xl.cfg.5.pod.i...
5 p.m.
Am Wed, 20 Feb 2019 17:20:39 -0700
schrieb Jim Fehlig <jfehlig(a)suse.com>:
There have been a few requests [1][2] to support Xen's
max_grant_frames setting
in libvirt domXML, but I'm not quite sure how to model it.
Thanks.
The change must also consider the case of an incoming VM:
With Xen 4.9 and earlier the only way to bump the value for all newly started domUs is to
boot Xen itself with gnttab_max_frames=N. If such domU is migrated to a newer Xen which
already has the per-domU knob max_grant_frames=, the new domU container will use the
(lower) default value of max_grant_frames= because the incoming JSON simply does not
contain that knob. So far I have not found a good place to inject the values from
"GNTTABOP_query_size" into the migration stream. If that stream is routed
through libvirtd by any chance, perhaps the stream can be tweaked there.
Olaf
7:42 a.m.
Adding xen-devel to cc in case anyone there wants to comment on my latest
proposal...
On 2/20/19 5:20 PM, Jim Fehlig wrote:
There have been a few requests [1][2] to support Xen's
max_grant_frames setting
in libvirt domXML, but I'm not quite sure how to model it. The documentation [3]
on this setting states:
Specify the maximum number of grant frames the domain is allowed to have. This
value controls how many pages the domain is able to grant access to for other
domains, needed e.g. for the operation of paravirtualized devices. The default
is settable via xl.conf(5).
I've sent a patch to introduce an analogous default in the libvirt libxl driver
https://www.redhat.com/archives/libvir-list/2019-March/msg00123.html
It smells of a <memtune> setting, e.g. the amount of memory a domain can share,
but doesn't map to any of the existing settings. A new subelement
<shared_limit>
doesn't feel right. Does anyone suggest a better way of modeling max_grant_frames?
After discussing the max_grant_frames setting a bit more with Juergen I had the
idea to model it as IO buffer space (or DMA space) of a xenbus "controller". All
PV devices in the guest connect to the xenbus controller and make use of the
available I/O buffer space. Guests with more PV devices requiring more buffer
can increase the space on the xenbus controller device.
One small wrinkle in this idea is that we currently don't model xenbus in
libvirt. I'd need to add support for a new xenbus controller type and start
implicitly creating it when creating guests with PV devices, similar to
auto-creation of controllers in the qemu driver. Also, there is no existing
controller setting for specifying buffer space. Perhaps a 'ram' attribute could
be added, similar to specifying memory for <video> devices? E.g.
<controller type='xenbus' ram='256'/>
Any opinion on this approach? Or other ideas for modeling this setting in libvirt?
Regards,
Jim
Another option I considered is setting the value based on number of PV devices,
but I think that flies in the face of libvirt's policy of not dictating policy.
Regardless of domain config modeling I can work on a driver-wide setting in
libxl.conf, similar to Xen's xl.conf(5) global.
Regards,
Jim
[1] https://www.redhat.com/archives/libvir-list/2018-April/msg00216.html
[2] https://www.redhat.com/archives/libvirt-users/2019-January/msg00011.html
[3]
http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/man/xl.cfg.5.pod.i...
5:02 p.m.
On Mon, Mar 04, 2019 at 04:42:32PM -0700, Jim Fehlig wrote:
Adding xen-devel to cc in case anyone there wants to comment on my
latest
proposal...
On 2/20/19 5:20 PM, Jim Fehlig wrote:
> There have been a few requests [1][2] to support Xen's max_grant_frames
> setting in libvirt domXML, but I'm not quite sure how to model it. The
> documentation [3] on this setting states:
>
> Specify the maximum number of grant frames the domain is allowed to have. This
> value controls how many pages the domain is able to grant access to for other
> domains, needed e.g. for the operation of paravirtualized devices. The default
> is settable via xl.conf(5).
I've sent a patch to introduce an analogous default in the libvirt libxl driver
https://www.redhat.com/archives/libvir-list/2019-March/msg00123.html
>
> It smells of a <memtune> setting, e.g. the amount of memory a domain can
> share, but doesn't map to any of the existing settings. A new subelement
> <shared_limit> doesn't feel right. Does anyone suggest a better way of
> modeling max_grant_frames?
After discussing the max_grant_frames setting a bit more with Juergen I had
the idea to model it as IO buffer space (or DMA space) of a xenbus
"controller". All PV devices in the guest connect to the xenbus controller
and make use of the available I/O buffer space. Guests with more PV devices
requiring more buffer can increase the space on the xenbus controller
device.
One small wrinkle in this idea is that we currently don't model xenbus in
libvirt. I'd need to add support for a new xenbus controller type and start
implicitly creating it when creating guests with PV devices, similar to
auto-creation of controllers in the qemu driver. Also, there is no existing
controller setting for specifying buffer space. Perhaps a 'ram' attribute
could be added, similar to specifying memory for <video> devices? E.g.
<controller type='xenbus' ram='256'/>
Any opinion on this approach? Or other ideas for modeling this setting
in libvirt?
Regardless of max grant frames support I think modeling xenbus as a
<controller> is a reasonable thing to want to do. I don't have a
preference on whether you call it "ram" or explicitly
"maxGrantFrames"
as an attribute.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
2069
days inactive
2082
days old
3 comments
3 participants
participants (3)
-
Daniel P. Berrangé -
Jim Fehlig -
Olaf Hering