Re: [Xen-devel] [RFC PATCH] Boot PV guests with more than 128GB (v1) for 3.7
>>> On 27.07.12 at 12:21, Ian Campbell wrote: > I was actually think of the issue with 32 bit PV guests accessing MFN > space > 160G, even if they are themselves small, which is a separate > concern. That can be made work if really needed, but not via the mechanism we're talking about here. The question is whether it's worth it. Jan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] [RFC PATCH] Boot PV guests with more than 128GB (v1) for 3.7
On Fri, 2012-07-27 at 11:17 +0100, Jan Beulich wrote: > >>> On 27.07.12 at 12:00, Ian Campbell wrote: > > On Fri, 2012-07-27 at 08:34 +0100, Jan Beulich wrote: > >> >>> On 26.07.12 at 22:47, Konrad Rzeszutek Wilk > >> >>> wrote: > >> > 2). Allocate a new array, copy the existing P2M into it, > >> > revector the P2M tree to use that, and return the old > >> > P2M to the memory allocate. This has the advantage that > >> > it sets the stage for using XEN_ELF_NOTE_INIT_P2M > >> > feature. That feature allows us to set the exact virtual > >> > address space we want for the P2M - and allows us to > >> > boot as initial domain on large machines. > >> > >> And I would hope that the tools would get updated to recognize > >> this note too, so that huge DomU-s would become possible as > >> well. > > > > Does this help us with >160GB 32 bit PV guests too? I'm guessing not > > since the real limitation there is the relatively small amount of kernel > > address space. > > Correct - 32-bit PV guests are limited anyway (and it's for a > reason the Dom0 support in the hypervisor only deals with > 64-bit ones). And honestly, considering the huge page > information table such a memory amount would require, I > doubt this big a PV guest would even boot (or if it does, be > of any use). Right. I was actually think of the issue with 32 bit PV guests accessing MFN space > 160G, even if they are themselves small, which is a separate concern. Ian. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] [RFC PATCH] Boot PV guests with more than 128GB (v1) for 3.7
>>> On 27.07.12 at 12:00, Ian Campbell wrote: > On Fri, 2012-07-27 at 08:34 +0100, Jan Beulich wrote: >> >>> On 26.07.12 at 22:47, Konrad Rzeszutek Wilk >> >>> wrote: >> > 2). Allocate a new array, copy the existing P2M into it, >> > revector the P2M tree to use that, and return the old >> > P2M to the memory allocate. This has the advantage that >> > it sets the stage for using XEN_ELF_NOTE_INIT_P2M >> > feature. That feature allows us to set the exact virtual >> > address space we want for the P2M - and allows us to >> > boot as initial domain on large machines. >> >> And I would hope that the tools would get updated to recognize >> this note too, so that huge DomU-s would become possible as >> well. > > Does this help us with >160GB 32 bit PV guests too? I'm guessing not > since the real limitation there is the relatively small amount of kernel > address space. Correct - 32-bit PV guests are limited anyway (and it's for a reason the Dom0 support in the hypervisor only deals with 64-bit ones). And honestly, considering the huge page information table such a memory amount would require, I doubt this big a PV guest would even boot (or if it does, be of any use). Jan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] [RFC PATCH] Boot PV guests with more than 128GB (v1) for 3.7
On Fri, 2012-07-27 at 08:34 +0100, Jan Beulich wrote: > >>> On 26.07.12 at 22:47, Konrad Rzeszutek Wilk > >>> wrote: > > 2). Allocate a new array, copy the existing P2M into it, > > revector the P2M tree to use that, and return the old > > P2M to the memory allocate. This has the advantage that > > it sets the stage for using XEN_ELF_NOTE_INIT_P2M > > feature. That feature allows us to set the exact virtual > > address space we want for the P2M - and allows us to > > boot as initial domain on large machines. > > And I would hope that the tools would get updated to recognize > this note too, so that huge DomU-s would become possible as > well. Does this help us with >160GB 32 bit PV guests too? I'm guessing not since the real limitation there is the relatively small amount of kernel address space. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] [RFC PATCH] Boot PV guests with more than 128GB (v1) for 3.7
>>> On 26.07.12 at 22:47, Konrad Rzeszutek Wilk wrote: > 2). Allocate a new array, copy the existing P2M into it, > revector the P2M tree to use that, and return the old > P2M to the memory allocate. This has the advantage that > it sets the stage for using XEN_ELF_NOTE_INIT_P2M > feature. That feature allows us to set the exact virtual > address space we want for the P2M - and allows us to > boot as initial domain on large machines. And I would hope that the tools would get updated to recognize this note too, so that huge DomU-s would become possible as well. Jan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] [RFC PATCH] Boot PV guests with more than 128GB (v1) for 3.7
On 26.07.12 at 22:47, Konrad Rzeszutek Wilk konrad.w...@oracle.com wrote: 2). Allocate a new array, copy the existing P2M into it, revector the P2M tree to use that, and return the old P2M to the memory allocate. This has the advantage that it sets the stage for using XEN_ELF_NOTE_INIT_P2M feature. That feature allows us to set the exact virtual address space we want for the P2M - and allows us to boot as initial domain on large machines. And I would hope that the tools would get updated to recognize this note too, so that huge DomU-s would become possible as well. Jan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] [RFC PATCH] Boot PV guests with more than 128GB (v1) for 3.7
On Fri, 2012-07-27 at 08:34 +0100, Jan Beulich wrote: On 26.07.12 at 22:47, Konrad Rzeszutek Wilk konrad.w...@oracle.com wrote: 2). Allocate a new array, copy the existing P2M into it, revector the P2M tree to use that, and return the old P2M to the memory allocate. This has the advantage that it sets the stage for using XEN_ELF_NOTE_INIT_P2M feature. That feature allows us to set the exact virtual address space we want for the P2M - and allows us to boot as initial domain on large machines. And I would hope that the tools would get updated to recognize this note too, so that huge DomU-s would become possible as well. Does this help us with 160GB 32 bit PV guests too? I'm guessing not since the real limitation there is the relatively small amount of kernel address space. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] [RFC PATCH] Boot PV guests with more than 128GB (v1) for 3.7
On 27.07.12 at 12:00, Ian Campbell ian.campb...@citrix.com wrote: On Fri, 2012-07-27 at 08:34 +0100, Jan Beulich wrote: On 26.07.12 at 22:47, Konrad Rzeszutek Wilk konrad.w...@oracle.com wrote: 2). Allocate a new array, copy the existing P2M into it, revector the P2M tree to use that, and return the old P2M to the memory allocate. This has the advantage that it sets the stage for using XEN_ELF_NOTE_INIT_P2M feature. That feature allows us to set the exact virtual address space we want for the P2M - and allows us to boot as initial domain on large machines. And I would hope that the tools would get updated to recognize this note too, so that huge DomU-s would become possible as well. Does this help us with 160GB 32 bit PV guests too? I'm guessing not since the real limitation there is the relatively small amount of kernel address space. Correct - 32-bit PV guests are limited anyway (and it's for a reason the Dom0 support in the hypervisor only deals with 64-bit ones). And honestly, considering the huge page information table such a memory amount would require, I doubt this big a PV guest would even boot (or if it does, be of any use). Jan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] [RFC PATCH] Boot PV guests with more than 128GB (v1) for 3.7
On Fri, 2012-07-27 at 11:17 +0100, Jan Beulich wrote: On 27.07.12 at 12:00, Ian Campbell ian.campb...@citrix.com wrote: On Fri, 2012-07-27 at 08:34 +0100, Jan Beulich wrote: On 26.07.12 at 22:47, Konrad Rzeszutek Wilk konrad.w...@oracle.com wrote: 2). Allocate a new array, copy the existing P2M into it, revector the P2M tree to use that, and return the old P2M to the memory allocate. This has the advantage that it sets the stage for using XEN_ELF_NOTE_INIT_P2M feature. That feature allows us to set the exact virtual address space we want for the P2M - and allows us to boot as initial domain on large machines. And I would hope that the tools would get updated to recognize this note too, so that huge DomU-s would become possible as well. Does this help us with 160GB 32 bit PV guests too? I'm guessing not since the real limitation there is the relatively small amount of kernel address space. Correct - 32-bit PV guests are limited anyway (and it's for a reason the Dom0 support in the hypervisor only deals with 64-bit ones). And honestly, considering the huge page information table such a memory amount would require, I doubt this big a PV guest would even boot (or if it does, be of any use). Right. I was actually think of the issue with 32 bit PV guests accessing MFN space 160G, even if they are themselves small, which is a separate concern. Ian. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] [RFC PATCH] Boot PV guests with more than 128GB (v1) for 3.7
On 27.07.12 at 12:21, Ian Campbell ian.campb...@citrix.com wrote: I was actually think of the issue with 32 bit PV guests accessing MFN space 160G, even if they are themselves small, which is a separate concern. That can be made work if really needed, but not via the mechanism we're talking about here. The question is whether it's worth it. Jan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
