* Re: [libvirt] domXML modeling question [not found] <d8f69df7-a2a0-7903-d07a-8d3f86670c22@suse.com> @ 2019-03-04 23:42 ` Jim Fehlig [not found] ` <abf3045a-e22d-aaf1-4881-58ed4c665f7f@suse.com> 1 sibling, 0 replies; 2+ messages in thread From: Jim Fehlig @ 2019-03-04 23:42 UTC (permalink / raw) To: LibVir; +Cc: Juergen Gross, xen-devel, Christoph, Olaf Hering 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.in;h=ad81af1ed8cc983c76b5ec2c3aa02e28f042cc63;hb=HEAD#l569 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 2+ messages in thread
[parent not found: <abf3045a-e22d-aaf1-4881-58ed4c665f7f@suse.com>]
* Re: [libvirt] domXML modeling question [not found] ` <abf3045a-e22d-aaf1-4881-58ed4c665f7f@suse.com> @ 2019-03-06 9:02 ` Daniel P. Berrangé 0 siblings, 0 replies; 2+ messages in thread From: Daniel P. Berrangé @ 2019-03-06 9:02 UTC (permalink / raw) To: Jim Fehlig; +Cc: LibVir, Juergen Gross, Christoph, Olaf Hering, xen-devel 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 :| _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2019-03-06 9:02 UTC | newest] Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <d8f69df7-a2a0-7903-d07a-8d3f86670c22@suse.com> 2019-03-04 23:42 ` [libvirt] domXML modeling question Jim Fehlig [not found] ` <abf3045a-e22d-aaf1-4881-58ed4c665f7f@suse.com> 2019-03-06 9:02 ` Daniel P. Berrangé
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.