On 09/11/2018 12:46 AM, John Ferlan wrote: > > On 09/07/2018 07:32 AM, marcandre.lureau@xxxxxxxxxx wrote: >> From: Marc-André Lureau <marcandre.lureau@xxxxxxxxxx> >> > > Would be nice to have a few more words here. If you provide them I can > add them... The if statement is difficult to read unless you know what > each field really means. > > secondary question - should we document what gets used?, e.g.: > > https://libvirt.org/formatdomain.html#elementsMemoryBacking > > Seems to me the preference to use memfd is for memory backing using > anonymous source for nvdimm's without a defined path, but sometimes my > wording doesn't match reality. I don't think we want to tell users what backend are we going to use under what conditions. Firstly, these conditions will change (as they did in the past). Secondly, what backend libvirt decides to use is no business of users. I mean, they care about providing XML that matches their demands. It's libvirt's job to fulfil them. Look at this from the other way: if an user wants to have memory-backend-file for his domain, how would they enforce it once memfd is merged? Sure, they can tweak their memoryBacking settings, but that would work only until we decide to change the decision process for mem backend. What I am more worried about is migration. What happens if I migrate a hugepages domain from older libvirt to a newer one (the former doesn't support memfd, the latter does). On the source the domain was started with memory-backend-file (or memory-backend-ram with -mem-path). And during migration, the generated cmd line would use memfd. And I don't think qemu is capable of dealing with this discrepancy, is it? Or is memfd going to be used only for hugepages + <source type='anonymous'/> case (which is not allowed now and thus migration scenario I'm describing can't happen)? Michal -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
