Re: [Xen-devel] [PATCH] x86: add feature flags to shared_info page

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 02/03/15 15:40, Juergen Gross wrote:
> On 03/02/2015 04:22 PM, Andrew Cooper wrote:
>> On 02/03/15 15:11, Juergen Gross wrote:
>>> On 03/02/2015 02:56 PM, Jan Beulich wrote:
>>>>>>> On 02.03.15 at 14:44, <andrew.cooper3@xxxxxxxxxx> wrote:
>>>>> On 02/03/15 13:15, Jan Beulich wrote:
>>>>>>>>> On 02.03.15 at 13:59, <"jgross@xxxxxxxx".non-mime.internet>
>>>>>>>>> wrote:
>>>>>>> In order to indicate the Xen tools capability to support the
>>>>>>> virtual
>>>>>>> mapped linear p2m list instead the 3 level mfn tree add feature
>>>>>>> flags
>>>>>>> to the shared_info page.
>>>>>> But why in the shared info page? They'd belong to start info or
>>>>>> should
>>>>>> be obtainable via XENVER_get_features.
>>>>>
>>>>> Furthermore in this case, the virtual linear p2m is purely a
>>>>> guest->toolstack feature/ABI.
>>>>>
>>>>> Xen deliberately has no knowledge of PV guest p2ms of either the
>>>>> 3level
>>>>> or linear variety.
>>>>>
>>>>> Is there genuinely no better interface than the hypervisor feature
>>>>> flags
>>>>> to indicate a piece of toolstack support?
>>>>
>>>> As Ian indicated in his reply, much depends on whether any other
>>>> mechanism would allow the information to be retrieved early enough
>>>> in the guest.
>>>
>>> Options that would work are, regarding the time the information is
>>> needed:
>>>
>>> - XENVER_get_features
>>> - start info
>>> - shared info
>>> - any (other) hypercall
>>>
>>> All other interfaces are available much too late.
>>>
>>> I think start info is the best option, as it is built by the tools for
>>> domUs and, as Jan already mentioned, would be a better place for the
>>> information as shared info.
>>
>> I concur.  The start info seems like the best place for it.
>>
>>>
>>> The last remaining question: what to do regarding dom0? Here I see the
>>> following alternatives:
>>>
>>> - do nothing: the 3 level mfn tree is built even if it is not needed,
>>>    wastes up to 2MB memory and might slow down dom0 (I doubt the slow
>>>    down would be detectable)
>>> - set the flag based on a hypervisor boot parameter (not very nice)
>>> - throw the 3 level mfn tree away during boot as soon as the tools can
>>>    tell dom0 to do so (requires a new interface)
>>>
>>> Any thoughts?
>>
>> The toolstack only needs to access the p2m when doing suspend/resume for
>> migrate, or a coredump.  None of these are applicable to dom0, so I
>> think dom0 can get away with doing whatever it prefers in this regard.
>
> Are core dumps of dom0 really no issue? I think crash is using the 3
> level mfn tree today.

The only coredump of dom0 you are ever going to find is via /proc/vmcore
of a kdump environment, which is a Xen coredump with dom0 being just
another domain.

I have not used `crash` in this scenario, but it would be actively
making work for itself to attempt to piece dom0 back into a regular
image similar to `xl dump-core`, rather than simply using cr3 available
from struct vcpu.

So long as there is a kernel command line option available, the user who
sets up the crash environment can force it back into a state that their
tools expect.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel