Re: [Xen-devel] [PATCH 4/5] OvmfPkg/XenPlatformPei: Calibrate APIC timer frequency

[Andrew Cooper <andrew.cooper3@citrix.com>]

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