[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 1/4] expand x86 arch_shared_info to support linear p2m list
>>> On 21.11.14 at 14:37, <JGross@xxxxxxxx> 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'm okay with that, but would think p2m_pt_root would be more generic. Considering PAE, wouldn't this need to be a 64-bit value then even in the 32-bit interface? Or alternatively be represented as MFN instead? Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |