Re: [Xen-devel] [PATCH 1/4] expand x86 arch_shared_info to support linear p2m list

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 21/11/14 13:37, Jürgen Groß wrote:
> On 11/21/2014 02:26 PM, Andrew Cooper wrote:
>> On 21/11/14 12:57, Juergen Gross wrote:
>>> On 11/21/2014 01:23 PM, Jan Beulich wrote:
>>>>>>> On 14.11.14 at 10:37, <"jgross@xxxxxxxx".non-mime.internet> wrote:
>>>>> --- a/xen/include/public/arch-x86/xen.h
>>>>> +++ b/xen/include/public/arch-x86/xen.h
>>>>> @@ -224,7 +224,12 @@ struct arch_shared_info {
>>>>>        /* Frame containing list of mfns containing list of mfns
>>>>> containing p2m. */
>>>>>        xen_pfn_t     pfn_to_mfn_frame_list_list;
>>>>>        unsigned long nmi_reason;
>>>>> -    uint64_t pad[32];
>>>>> +    /*
>>>>> +     * Following two fields are valid if pfn_to_mfn_frame_list_list
>>>>> contains
>>>>> +     * ~0UL.
>>>>> +     */
>>>>> +    unsigned long p2m_vaddr;    /* virtual address of the p2m
>>>>> list */
>>>>> +    unsigned long p2m_as_root;  /* mfn of the top level page
>>>>> table */
>>>>
>>>> xen_pfn_t please. And what does the "as" in the name stand for?
>>>
>>> "as" is address space. I can rename it to e.g. "p2m_pgd_mfn".
>>
>> That is a linuxism in naming, which is also not accurate.
>>
>>  From my understanding, this frame must be an L4 table for 64bit guests,
>> and an L3 table for 32bit guests.  I.e. it is effectively a cr3 with
>> which to use the p2m_vaddr field above?
>
> Okay, so p2m_cr3 then?
>
>

I think that is reasonable, along with the comment explaining that it
must reference an L4 or L3 frame, depending on the width of the guest. 
In the case of a 32bit guest, it should be a magic folded pfn, in the
same representation that cr3 has in the vcpu register state.

~Andrew


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