| Message ID | 5911ED1902000078001583C3@prv-mh.provo.novell.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 09/05/17 16:23, Jan Beulich wrote: > Since PV kernels can't use large pages anywa, when the init-P2M support > was added it was decided to keep the implementation simple and not > align large pages in PFN space. Document this. > > Signed-off-by: Jan Beulich <jbeulich@suse.com> > > --- a/xen/include/public/elfnote.h > +++ b/xen/include/public/elfnote.h > @@ -173,7 +173,9 @@ > * The (non-default) location the initial phys-to-machine map should be > * placed at by the hypervisor (Dom0) or the tools (DomU). > * The kernel must be prepared for this mapping to be established using > - * large pages, despite such otherwise not being available to guests. > + * large pages, despite such otherwise not being available to guests. Note Shouldn't the large page usage be limited to dom0? Juergen > + * that these large pages may be misaligned in PFN space (they'll obviously > + * be aligned in MFN and virtual address spaces). > * The kernel must also be able to handle the page table pages used for > * this mapping not being accessible through the initial mapping. > * (Only x86-64 supports this at present.) > > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > https://lists.xen.org/xen-devel >
>>> On 09.05.17 at 16:36, <jgross@suse.com> wrote: > On 09/05/17 16:23, Jan Beulich wrote: >> Since PV kernels can't use large pages anywa, when the init-P2M support >> was added it was decided to keep the implementation simple and not >> align large pages in PFN space. Document this. >> >> Signed-off-by: Jan Beulich <jbeulich@suse.com> >> >> --- a/xen/include/public/elfnote.h >> +++ b/xen/include/public/elfnote.h >> @@ -173,7 +173,9 @@ >> * The (non-default) location the initial phys-to-machine map should be >> * placed at by the hypervisor (Dom0) or the tools (DomU). >> * The kernel must be prepared for this mapping to be established using >> - * large pages, despite such otherwise not being available to guests. >> + * large pages, despite such otherwise not being available to guests. Note > > Shouldn't the large page usage be limited to dom0? Why? Even if the tools right now don't use large pages here, why should we preclude them wanting to at some point? Jan
On 09/05/17 15:23, Jan Beulich wrote: > Since PV kernels can't use large pages anywa, when the init-P2M support anyway ~Andrew > was added it was decided to keep the implementation simple and not > align large pages in PFN space. Document this. > > Signed-off-by: Jan Beulich <jbeulich@suse.com> > > --- a/xen/include/public/elfnote.h > +++ b/xen/include/public/elfnote.h > @@ -173,7 +173,9 @@ > * The (non-default) location the initial phys-to-machine map should be > * placed at by the hypervisor (Dom0) or the tools (DomU). > * The kernel must be prepared for this mapping to be established using > - * large pages, despite such otherwise not being available to guests. > + * large pages, despite such otherwise not being available to guests. Note > + * that these large pages may be misaligned in PFN space (they'll obviously > + * be aligned in MFN and virtual address spaces). > * The kernel must also be able to handle the page table pages used for > * this mapping not being accessible through the initial mapping. > * (Only x86-64 supports this at present.) > > >
>>> On 09.05.17 at 17:10, <andrew.cooper3@citrix.com> wrote: > On 09/05/17 15:23, Jan Beulich wrote: >> Since PV kernels can't use large pages anywa, when the init-P2M support > > anyway Already fixed after Alan pointed this out. Do I need to send v2 because of this typo? Jan
On 09/05/17 17:06, Jan Beulich wrote: >>>> On 09.05.17 at 16:36, <jgross@suse.com> wrote: >> On 09/05/17 16:23, Jan Beulich wrote: >>> Since PV kernels can't use large pages anywa, when the init-P2M support >>> was added it was decided to keep the implementation simple and not >>> align large pages in PFN space. Document this. >>> >>> Signed-off-by: Jan Beulich <jbeulich@suse.com> >>> >>> --- a/xen/include/public/elfnote.h >>> +++ b/xen/include/public/elfnote.h >>> @@ -173,7 +173,9 @@ >>> * The (non-default) location the initial phys-to-machine map should be >>> * placed at by the hypervisor (Dom0) or the tools (DomU). >>> * The kernel must be prepared for this mapping to be established using >>> - * large pages, despite such otherwise not being available to guests. >>> + * large pages, despite such otherwise not being available to guests. Note >> >> Shouldn't the large page usage be limited to dom0? > > Why? Even if the tools right now don't use large pages here, why > should we preclude them wanting to at some point? Those could be of temporary nature only in order not to break migration. So the guest would be forced to split the big pages up anyway. Why create them in the beginning then? Juergen
>>> On 09.05.17 at 17:25, <jgross@suse.com> wrote: > On 09/05/17 17:06, Jan Beulich wrote: >>>>> On 09.05.17 at 16:36, <jgross@suse.com> wrote: >>> On 09/05/17 16:23, Jan Beulich wrote: >>>> Since PV kernels can't use large pages anywa, when the init-P2M support >>>> was added it was decided to keep the implementation simple and not >>>> align large pages in PFN space. Document this. >>>> >>>> Signed-off-by: Jan Beulich <jbeulich@suse.com> >>>> >>>> --- a/xen/include/public/elfnote.h >>>> +++ b/xen/include/public/elfnote.h >>>> @@ -173,7 +173,9 @@ >>>> * The (non-default) location the initial phys-to-machine map should be >>>> * placed at by the hypervisor (Dom0) or the tools (DomU). >>>> * The kernel must be prepared for this mapping to be established using >>>> - * large pages, despite such otherwise not being available to guests. >>>> + * large pages, despite such otherwise not being available to guests. Note >>> >>> Shouldn't the large page usage be limited to dom0? >> >> Why? Even if the tools right now don't use large pages here, why >> should we preclude them wanting to at some point? > > Those could be of temporary nature only in order not to break migration. > So the guest would be forced to split the big pages up anyway. Why > create them in the beginning then? As long as the migration stream doesn't represent them as 1Gb or 2Mb pages, I don't see how they would get in the way of migration. Jan
On 09/05/17 17:32, Jan Beulich wrote: >>>> On 09.05.17 at 17:25, <jgross@suse.com> wrote: >> On 09/05/17 17:06, Jan Beulich wrote: >>>>>> On 09.05.17 at 16:36, <jgross@suse.com> wrote: >>>> On 09/05/17 16:23, Jan Beulich wrote: >>>>> Since PV kernels can't use large pages anywa, when the init-P2M support >>>>> was added it was decided to keep the implementation simple and not >>>>> align large pages in PFN space. Document this. >>>>> >>>>> Signed-off-by: Jan Beulich <jbeulich@suse.com> >>>>> >>>>> --- a/xen/include/public/elfnote.h >>>>> +++ b/xen/include/public/elfnote.h >>>>> @@ -173,7 +173,9 @@ >>>>> * The (non-default) location the initial phys-to-machine map should be >>>>> * placed at by the hypervisor (Dom0) or the tools (DomU). >>>>> * The kernel must be prepared for this mapping to be established using >>>>> - * large pages, despite such otherwise not being available to guests. >>>>> + * large pages, despite such otherwise not being available to guests. Note >>>> >>>> Shouldn't the large page usage be limited to dom0? >>> >>> Why? Even if the tools right now don't use large pages here, why >>> should we preclude them wanting to at some point? >> >> Those could be of temporary nature only in order not to break migration. >> So the guest would be forced to split the big pages up anyway. Why >> create them in the beginning then? > > As long as the migration stream doesn't represent them as 1Gb or > 2Mb pages, I don't see how they would get in the way of migration. How would the receiving side allocate the additional page tables? Juergen
Hi, On 09/05/17 15:23, Jan Beulich wrote: > Since PV kernels can't use large pages anywa, when the init-P2M support > was added it was decided to keep the implementation simple and not > align large pages in PFN space. Document this. > > Signed-off-by: Jan Beulich <jbeulich@suse.com> This is documentation so: Release-acked-by: Julien Grall <julien.grall@arm.com> Cheers, > > --- a/xen/include/public/elfnote.h > +++ b/xen/include/public/elfnote.h > @@ -173,7 +173,9 @@ > * The (non-default) location the initial phys-to-machine map should be > * placed at by the hypervisor (Dom0) or the tools (DomU). > * The kernel must be prepared for this mapping to be established using > - * large pages, despite such otherwise not being available to guests. > + * large pages, despite such otherwise not being available to guests. Note > + * that these large pages may be misaligned in PFN space (they'll obviously > + * be aligned in MFN and virtual address spaces). > * The kernel must also be able to handle the page table pages used for > * this mapping not being accessible through the initial mapping. > * (Only x86-64 supports this at present.) > > >
>>> On 09.05.17 at 17:33, <jgross@suse.com> wrote: > On 09/05/17 17:32, Jan Beulich wrote: >>>>> On 09.05.17 at 17:25, <jgross@suse.com> wrote: >>> On 09/05/17 17:06, Jan Beulich wrote: >>>>>>> On 09.05.17 at 16:36, <jgross@suse.com> wrote: >>>>> On 09/05/17 16:23, Jan Beulich wrote: >>>>>> Since PV kernels can't use large pages anywa, when the init-P2M support >>>>>> was added it was decided to keep the implementation simple and not >>>>>> align large pages in PFN space. Document this. >>>>>> >>>>>> Signed-off-by: Jan Beulich <jbeulich@suse.com> >>>>>> >>>>>> --- a/xen/include/public/elfnote.h >>>>>> +++ b/xen/include/public/elfnote.h >>>>>> @@ -173,7 +173,9 @@ >>>>>> * The (non-default) location the initial phys-to-machine map should be >>>>>> * placed at by the hypervisor (Dom0) or the tools (DomU). >>>>>> * The kernel must be prepared for this mapping to be established using >>>>>> - * large pages, despite such otherwise not being available to guests. >>>>>> + * large pages, despite such otherwise not being available to guests. Note >>>>> >>>>> Shouldn't the large page usage be limited to dom0? >>>> >>>> Why? Even if the tools right now don't use large pages here, why >>>> should we preclude them wanting to at some point? >>> >>> Those could be of temporary nature only in order not to break migration. >>> So the guest would be forced to split the big pages up anyway. Why >>> create them in the beginning then? >> >> As long as the migration stream doesn't represent them as 1Gb or >> 2Mb pages, I don't see how they would get in the way of migration. > > How would the receiving side allocate the additional page tables? Oh, indeed. Yet still, guests not intended to be migrated could be built that way. I don't think we should allow kernel side relaxation here. Jan
On 09/05/17 17:02, Jan Beulich wrote: >>>> On 09.05.17 at 17:33, <jgross@suse.com> wrote: >> On 09/05/17 17:32, Jan Beulich wrote: >>>>>> On 09.05.17 at 17:25, <jgross@suse.com> wrote: >>>> On 09/05/17 17:06, Jan Beulich wrote: >>>>>>>> On 09.05.17 at 16:36, <jgross@suse.com> wrote: >>>>>> On 09/05/17 16:23, Jan Beulich wrote: >>>>>>> Since PV kernels can't use large pages anywa, when the init-P2M support >>>>>>> was added it was decided to keep the implementation simple and not >>>>>>> align large pages in PFN space. Document this. >>>>>>> >>>>>>> Signed-off-by: Jan Beulich <jbeulich@suse.com> >>>>>>> >>>>>>> --- a/xen/include/public/elfnote.h >>>>>>> +++ b/xen/include/public/elfnote.h >>>>>>> @@ -173,7 +173,9 @@ >>>>>>> * The (non-default) location the initial phys-to-machine map should be >>>>>>> * placed at by the hypervisor (Dom0) or the tools (DomU). >>>>>>> * The kernel must be prepared for this mapping to be established using >>>>>>> - * large pages, despite such otherwise not being available to guests. >>>>>>> + * large pages, despite such otherwise not being available to guests. Note >>>>>> Shouldn't the large page usage be limited to dom0? >>>>> Why? Even if the tools right now don't use large pages here, why >>>>> should we preclude them wanting to at some point? >>>> Those could be of temporary nature only in order not to break migration. >>>> So the guest would be forced to split the big pages up anyway. Why >>>> create them in the beginning then? >>> As long as the migration stream doesn't represent them as 1Gb or >>> 2Mb pages, I don't see how they would get in the way of migration. >> How would the receiving side allocate the additional page tables? > Oh, indeed. Yet still, guests not intended to be migrated could be > built that way. I don't think we should allow kernel side relaxation > here. The save side of PV migrate will cleanly abort if it finds any superpages, precisely because we have no idea whether the destination can allocate the frames. ~Andrew
On 09/05/17 16:23, Jan Beulich wrote: >>>> On 09.05.17 at 17:10, <andrew.cooper3@citrix.com> wrote: >> On 09/05/17 15:23, Jan Beulich wrote: >>> Since PV kernels can't use large pages anywa, when the init-P2M support >> anyway > Already fixed after Alan pointed this out. Do I need to send v2 > because of this typo? No. Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
--- a/xen/include/public/elfnote.h +++ b/xen/include/public/elfnote.h @@ -173,7 +173,9 @@ * The (non-default) location the initial phys-to-machine map should be * placed at by the hypervisor (Dom0) or the tools (DomU). * The kernel must be prepared for this mapping to be established using - * large pages, despite such otherwise not being available to guests. + * large pages, despite such otherwise not being available to guests. Note + * that these large pages may be misaligned in PFN space (they'll obviously + * be aligned in MFN and virtual address spaces). * The kernel must also be able to handle the page table pages used for * this mapping not being accessible through the initial mapping. * (Only x86-64 supports this at present.)