On 10/07/2012 19:09, "Olaf Hering" <olaf at aepfle.de> wrote: >>> Are there more shared areas or is it just the shared info page? >>> >>>> And I am kind of worried that moving it to the .data section won't >>>> be completly safe - as the decompressor might blow away that part too. >>> >>> The decompressor may just clear the area, but since there is no way to >>> tell where the shared pages are its always a risk to allocate them at >>> compile time. >> >> Yeah, and with the hypervisor potentially still updating the "old" >> MFN before the new kernel has registered the new MFN, we can end up >> corrupting the new kernel. Ouch. >> >> Would all of these issues disappear if the hypervisor had a hypercall >> that would stop updating the shared info? or just deregister the MFN? >> What if you ripped the GMFN out using 'decrease_reservation' hypercall? >> Would that eliminate the pesky GMFN? > > I'm not sure, most likely the gfn will just disappear from the guest, > like a ballooned page disappears. Accessing it will likely cause a > crash. Best thing to do, is possible, is map the shared-info page in the xen-platform pci device's BAR memory range. Then it will not conflict with any RAM. If you do map it over the top of an existing RAM page, you will have to repopulate that RAM page before kexec, using populate_physmap hypercall. The good news is that the populate_physmap hypercall will have the side effect of unmapping the shared-info page, reayd to be mapped wherever the new kernel would like it to reside :) Hope this clears up some of the confusion. ;) -- Keir
