[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] libxl refactoring, call for discussion
Hi Ian, I'll try to make clear domain restart thing first. Currently there are only device entries in domain config for frontends with backend paths in them, e.g.: FrontendDomain.cfg: vdevice = [ 'backend=BackendDomain,devid=0,device=/dev/device' ] it is parsed only on frontend domain start, and libxl creates both frontend and backend xenstore branches from that entry. Problem is, on backend domain restart libxl does not re-read this config, because it belongs to the frontend domain which is clearly not restarted, and as a consequence xenstore backend branches are cleared (on backend shutdown) but not filled again, because backend domain does not have any entries for this device. What I propose is to add information needed to fill xenstore backend branches to backend domains and remove it from frontend domains, so it would possibly look like this: FrontendDomain.cfg: frontend:vdevice = [ 'backend=BackendDomain,devid=0' ] BackendDomain.cfg: backend:vdevice = ['frontend=FrontendDomain,devid=0,device=/dev/device'] Now we have all the information needed for both domains to restart intependently filling their own xenstore branches. On FrontendDomain start libxl fills only frontend branch for vdevice, and on backendDomain startÂlibxlÂfills only backend branch. This can be easily done in backwards-compatible way: if frontend entry is filled in the old format, it is used to fill both branches, but if we explicitly state that it's only frontend or only backend entry, then it is used to fill only the corresponding branch. For the main part, that's it: currently the main thing we need is a DomD restart, and such a change would be enough for that purpose with no need for dirty hacks. But from that point we can make one step further: to remove split driver connection information from user domains. It would possibly look like this: FrontendDomain.cfg: frontend:vdevice = [ 'devid=0' ] BackendDomain.cfg: backend:vdevice = ['devid=0,devname=Main,device=/dev/device'] SupervisorDomain.cfg: backend:vdevice = ['devid=0,devname=Fallback,device=/dev/device'] connection:vdevice = ['devid=0,Âfrontend=FrontendDomain,Âbackend=BackendDomain, devname=Main'] connection:vdevice = ['devid=0,Âfrontend=FrontendDomain,Âbackend=SupervisorDomain, devname=Fallback'] Motivation for this example is the following: if we have, e.g., PV GPU which is used in user domain and we have restrictions on graphics availability, we can monitor if main device backend hanged and make a runtime switch to a fallback device (software rendering) till main backend would be restated. Connections are static, they generally do not change and do not actually belong to any user domain, so there is no need clearing and refilling them on every domain restart. This can be easily done in backwards-compatible way as well: if entries already have connection information, we stick to the old model; if they don't, we look for the connection branch to fill missing fields and to setup fallback paths. There still is an issue with hoplug devices being non-persistent (xl vdevice-attach fills both frontend and backend branches, but restart of any of user domains looses this information). At the moment we fix this rather dirty with additional 'hotplugged' xenstore branch bot belonging to any domain so it's not erased on shutdown but is being read on domain start if exists. In context of reworking libxl, I believe this one can be done as well, though I still don't have a solution I would like. Suikov Pavlo GlobalLogic P +x.xxx.xxx.xxxxÂÂM +38.066.667.1296Â S psujkov www.globallogic.com http://www.globallogic.com/email_disclaimer.txt On Wed, Jan 27, 2016 at 4:26 PM, Ian Campbell <ian.campbell@xxxxxxxxxx> wrote:
_______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |