On Mon, Oct 26, 2015 at 11:37:04AM -0600, Valerio Aimale wrote: > On 10/26/15 3:09 AM, Markus Armbruster wrote: > >[...] > > > >>Eduardo, I think it would be a common rule of politeness not to pass > >>any judgement on a person that you don't know, but for some texts in a > >>mailing list. I think I understand how mmap() works, and very well. > >> > >>Participating is this discussion has been a struggle for me. For the > >>good of the libvmi users, I have been trying to ignore the judgements, > >>the comments and so on. But, alas, I throw my hands up in the air, and > >>I surrender. > >I'm sorry we exceeded your tolerance for frustration. This mailing list > >can be tough. We try to be welcoming (believe it or not), but we too > >often fail (okay, that part is easily believable). > > > >To be honest, I had difficulties understanding your explanation, and > >ended up guessing. I figure Eduardo did the same, and guessed > >incorrectly. There but for the grace of God go I. > Well, I did scribble my C sample excerpt too fast. Participating in mailing > list is not part of my job description - I was short on time, I admit to > that. However, there is a big difference in saying "I do no understand your > explanation, please try again" and saying "you're confused about mmap()" > > I was trying to advocate the use of a shared mmap'ed region. The sharing > would be two-ways (RW for both) between the QEMU virtualizer and the libvmi > process. I envision that there could be a QEMU command line argument, such > as "--mmap-guest-memory <filename>" Understand that Eric feels strongly the > libvmi client should own the file name - I have not forgotten that. When > that command line argument is given, as part of the guest initialization, > QEMU creates a file of size equal to the size of the guest memory containing > all zeros, mmaps that file to the guest memory with PROT_READ|PROT_WRITE > and MAP_FILE|MAP_SHARED, then starts the guest.
This is basically what memory-backend-file (and the legacy -mem-path option) already does today, but it unlinks the file just after opening it. We can change it to accept a full filename and/or an option to make it not unlink the file after opening it. I don't remember if memory-backend-file is usable without -numa, but we could make it possible somehow. > And, if at all possible, > makes the filename querable via qmp and/or hmp, so that the filename of the > mmap would not need to be maintained in two different places, leading to > maintenance nightmares. You can probably query the memory-backend-file QOM properties using QMP, already. Then the filename could be exposed as a QOM property. -- Eduardo
