On 30/01/2020 12:44, Anthony PERARD wrote: > On Thu, Jan 30, 2020 at 10:12:51AM +0100, Roger Pau Monné wrote: >> On Wed, Jan 29, 2020 at 12:12:34PM +0000, Anthony PERARD wrote: >>> + Parameters.domid = DOMID_SELF; >>> + Parameters.gpfn = (UINTN) PagePtr >> EFI_PAGE_SHIFT; >>> + ReturnCode = XenHypercallMemoryOp (XENMEM_remove_from_physmap, >>> &Parameters); >> I'm afraid this will leave a hole in the p2m, and hence freeing the >> page back to OVMF is wrong (I assume this is what FreePages does in >> CalibrateLapicTimer), as the physical address would be unpopulated >> after the call to XENMEM_remove_from_physmap. > I guess there's more refactoring to do in OVMF, there are other's of > this kind of call, mostly in the PV drivers, XenBusDxe. > >>> + >>> + SharedInfo = AllocatePages (1); >> Hm, it's not the best approach to use a regular memory page to map the >> shared info: mapping it is very likely to cause superpage shattering, >> and once unmapped it leaves a hole in the p2m. > :-( > >> As a reference you could map the shared info page at maximum physical >> address allowed (after checking it's not populated) like Wei is doing >> for the Xen on HyperV work. > I'll look at what can be done with OVMF. > > Is there some kind of information that Xen could give? Or is it all > information that OVMF should keep track of? Or if Xen only have > XENMEM_memory_map, then OVMF already have this information.
We need to actually tackle the memory problem, and provide something correct via XENMEM_memory_map (/similar). So far, noone has actually started to try fixing the problem. Perhaps now is a good enough kick to get started. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
