[PATCH 0/2] xen: Allow xen tools to run in guest using 64K page granularity

[PATCH 0/2] xen: Allow xen tools to run in guest using 64K page granularity

[Julien Grall]

Hi all,

This small series are the only changes required in Xen in order to run a guest
using 64K page granularity on top of an unmodified Xen.

I'd like feedback from maintainers tools to know if it might be worth to
introduce a function xc_pagesize() replicating the behavior of getpagesize()
for Xen.

Sincerely yours,

Julien Grall (2):
  tools/xenstored: Use XC_PAGE_SIZE rather than getpagesize()
  tools/xenconsoled: Use XC_PAGE_SIZE rather than getpagesize()

 tools/console/daemon/io.c         | 4 ++--
 tools/xenstore/xenstored_domain.c | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

-- 
2.1.4

[PATCH 1/2] tools/xenstored: Use XC_PAGE_SIZE rather than getpagesize()

[Julien Grall]

From: Julien Grall <julien.grall@linaro.org>

Linux may not use the same page granularity as Xen. This will result to
a domain crash because it will try to map more page than required.

As the xenstore page size willl always be equal to a Xen page size, use
XC_PAGE_SIZE.

Signed-off-by: Julien Grall <julien.grall@citrix.com>
---
 tools/xenstore/xenstored_domain.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index 6d0394d..0776e39 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -172,7 +172,7 @@ static void *map_interface(domid_t domid, unsigned long mfn)
 			GNTTAB_RESERVED_XENSTORE, PROT_READ|PROT_WRITE);
 	} else {
 		return xc_map_foreign_range(*xc_handle, domid,
-			getpagesize(), PROT_READ|PROT_WRITE, mfn);
+			XC_PAGE_SIZE, PROT_READ|PROT_WRITE, mfn);
 	}
 }
 
@@ -181,7 +181,7 @@ static void unmap_interface(void *interface)
 	if (*xcg_handle != NULL)
 		xc_gnttab_munmap(*xcg_handle, interface, 1);
 	else
-		munmap(interface, getpagesize());
+		munmap(interface, XC_PAGE_SIZE);
 }
 
 static int destroy_domain(void *_domain)
-- 
2.1.4

[PATCH 2/2] tools/xenconsoled: Use XC_PAGE_SIZE rather than getpagesize()

[Julien Grall]

From: Julien Grall <julien.grall@linaro.org>

Linux may not use the same page granularity as Xen. This will result to
a domain crash because it will try to map more page than required.

As the console page size will always be equal to a Xen page size, use
XC_PAGE_SIZE.

Signed-off-by: Julien Grall <julien.grall@citrix.com>
---
 tools/console/daemon/io.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/console/daemon/io.c b/tools/console/daemon/io.c
index ac08b5b..e246c25 100644
--- a/tools/console/daemon/io.c
+++ b/tools/console/daemon/io.c
@@ -523,7 +523,7 @@ static void domain_unmap_interface(struct domain *dom)
 	if (xcg_handle && dom->ring_ref == -1)
 		xc_gnttab_munmap(xcg_handle, dom->interface, 1);
 	else
-		munmap(dom->interface, getpagesize());
+		munmap(dom->interface, XC_PAGE_SIZE);
 	dom->interface = NULL;
 	dom->ring_ref = -1;
 }
@@ -562,7 +562,7 @@ static int domain_create_ring(struct domain *dom)
 	if (!dom->interface) {
 		/* Fall back to xc_map_foreign_range */
 		dom->interface = xc_map_foreign_range(
-			xc, dom->domid, getpagesize(),
+			xc, dom->domid, XC_PAGE_SIZE,
 			PROT_READ|PROT_WRITE,
 			(unsigned long)ring_ref);
 		if (dom->interface == NULL) {
-- 
2.1.4

Re: [PATCH 0/2] xen: Allow xen tools to run in guest using 64K page granularity

[Julien Grall]

Hi,

Ping? I don't think this patch series depends on others (such as Linux
64K support) to review it.

Regards,

On 11/05/15 12:55, Julien Grall wrote:
> Hi all,
> 
> This small series are the only changes required in Xen in order to run a guest
> using 64K page granularity on top of an unmodified Xen.
> 
> I'd like feedback from maintainers tools to know if it might be worth to
> introduce a function xc_pagesize() replicating the behavior of getpagesize()
> for Xen.
> 
> Sincerely yours,
> 
> Julien Grall (2):
>   tools/xenstored: Use XC_PAGE_SIZE rather than getpagesize()
>   tools/xenconsoled: Use XC_PAGE_SIZE rather than getpagesize()
> 
>  tools/console/daemon/io.c         | 4 ++--
>  tools/xenstore/xenstored_domain.c | 4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 


-- 
Julien Grall

Re: [PATCH 0/2] xen: Allow xen tools to run in guest using 64K page granularity

[Wei Liu]

On Mon, May 11, 2015 at 12:55:34PM +0100, Julien Grall wrote:
> Hi all,
> 
> This small series are the only changes required in Xen in order to run a guest
> using 64K page granularity on top of an unmodified Xen.
> 
> I'd like feedback from maintainers tools to know if it might be worth to
> introduce a function xc_pagesize() replicating the behavior of getpagesize()
> for Xen.
> 

Can we start with documenting the ABI (?) for communicating between
guests with different page sizes?

Or at least mention the ring mfn always has the size of XC_PAGE_SIZE (if
that's the case).

Wei.

> Sincerely yours,
> 
> Julien Grall (2):
>   tools/xenstored: Use XC_PAGE_SIZE rather than getpagesize()
>   tools/xenconsoled: Use XC_PAGE_SIZE rather than getpagesize()
> 
>  tools/console/daemon/io.c         | 4 ++--
>  tools/xenstore/xenstored_domain.c | 4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> -- 
> 2.1.4

Re: [PATCH 0/2] xen: Allow xen tools to run in guest using 64K page granularity

[Ian Campbell]

On Thu, 2015-06-25 at 11:21 +0100, Wei Liu wrote:
> On Mon, May 11, 2015 at 12:55:34PM +0100, Julien Grall wrote:
> > Hi all,
> > 
> > This small series are the only changes required in Xen in order to run a guest
> > using 64K page granularity on top of an unmodified Xen.
> > 
> > I'd like feedback from maintainers tools to know if it might be worth to
> > introduce a function xc_pagesize() replicating the behavior of getpagesize()
> > for Xen.
> > 
> 
> Can we start with documenting the ABI (?) for communicating between
> guests with different page sizes?

We should certainly make it clearer what things are in terms of "Xen ABI
page size" vs "the guest's page size" and other things.

I think we can commit these two without that though?

> 
> Or at least mention the ring mfn always has the size of XC_PAGE_SIZE (if
> that's the case).
> 
> Wei.
> 
> > Sincerely yours,
> > 
> > Julien Grall (2):
> >   tools/xenstored: Use XC_PAGE_SIZE rather than getpagesize()
> >   tools/xenconsoled: Use XC_PAGE_SIZE rather than getpagesize()
> > 
> >  tools/console/daemon/io.c         | 4 ++--
> >  tools/xenstore/xenstored_domain.c | 4 ++--
> >  2 files changed, 4 insertions(+), 4 deletions(-)
> > 
> > -- 
> > 2.1.4

Re: [PATCH 0/2] xen: Allow xen tools to run in guest using 64K page granularity

[Wei Liu]

On Thu, Jun 25, 2015 at 12:23:26PM +0100, Ian Campbell wrote:
> On Thu, 2015-06-25 at 11:21 +0100, Wei Liu wrote:
> > On Mon, May 11, 2015 at 12:55:34PM +0100, Julien Grall wrote:
> > > Hi all,
> > > 
> > > This small series are the only changes required in Xen in order to run a guest
> > > using 64K page granularity on top of an unmodified Xen.
> > > 
> > > I'd like feedback from maintainers tools to know if it might be worth to
> > > introduce a function xc_pagesize() replicating the behavior of getpagesize()
> > > for Xen.
> > > 
> > 
> > Can we start with documenting the ABI (?) for communicating between
> > guests with different page sizes?
> 
> We should certainly make it clearer what things are in terms of "Xen ABI
> page size" vs "the guest's page size" and other things.
> 
> I think we can commit these two without that though?
> 

It worries me a bit due to the lack of document, though I have a hunch
these patches are correct.

Saying that Xen always use XC_PAGE_SIZE page for store and console
mfn is good enough.

Wei.

> > 
> > Or at least mention the ring mfn always has the size of XC_PAGE_SIZE (if
> > that's the case).
> > 
> > Wei.
> > 
> > > Sincerely yours,
> > > 
> > > Julien Grall (2):
> > >   tools/xenstored: Use XC_PAGE_SIZE rather than getpagesize()
> > >   tools/xenconsoled: Use XC_PAGE_SIZE rather than getpagesize()
> > > 
> > >  tools/console/daemon/io.c         | 4 ++--
> > >  tools/xenstore/xenstored_domain.c | 4 ++--
> > >  2 files changed, 4 insertions(+), 4 deletions(-)
> > > 
> > > -- 
> > > 2.1.4
> 

Re: [PATCH 0/2] xen: Allow xen tools to run in guest using 64K page granularity

[Wei Liu]

On Mon, May 11, 2015 at 12:55:34PM +0100, Julien Grall wrote:
> Hi all,
> 
> This small series are the only changes required in Xen in order to run a guest
> using 64K page granularity on top of an unmodified Xen.
> 
> I'd like feedback from maintainers tools to know if it might be worth to
> introduce a function xc_pagesize() replicating the behavior of getpagesize()
> for Xen.
> 
> Sincerely yours,
> 
> Julien Grall (2):
>   tools/xenstored: Use XC_PAGE_SIZE rather than getpagesize()
>   tools/xenconsoled: Use XC_PAGE_SIZE rather than getpagesize()
> 
>  tools/console/daemon/io.c         | 4 ++--
>  tools/xenstore/xenstored_domain.c | 4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)

Acked-by: Wei Liu <wei.liu2@citrix.com>

> 
> -- 
> 2.1.4

Re: [PATCH 0/2] xen: Allow xen tools to run in guest using 64K page granularity

[Julien Grall]

Hi,

On 25/06/2015 12:23, Ian Campbell wrote:
> On Thu, 2015-06-25 at 11:21 +0100, Wei Liu wrote:
>> On Mon, May 11, 2015 at 12:55:34PM +0100, Julien Grall wrote:
>>> Hi all,
>>>
>>> This small series are the only changes required in Xen in order to run a guest
>>> using 64K page granularity on top of an unmodified Xen.
>>>
>>> I'd like feedback from maintainers tools to know if it might be worth to
>>> introduce a function xc_pagesize() replicating the behavior of getpagesize()
>>> for Xen.
>>>
>>
>> Can we start with documenting the ABI (?) for communicating between
>> guests with different page sizes?
>
> We should certainly make it clearer what things are in terms of "Xen ABI
> page size" vs "the guest's page size" and other things.

Don't we already say somewhere that the page granularity for the 
hypercall (though I haven't found it).

I can send a follow-up to clarify the page granularity for each PV protocol.

Regards,

-- 
Julien Grall

Re: [PATCH 0/2] xen: Allow xen tools to run in guest using 64K page granularity

[Julien Grall]

Hi Ian,

On 25/06/15 12:23, Ian Campbell wrote:
> On Thu, 2015-06-25 at 11:21 +0100, Wei Liu wrote:
>> On Mon, May 11, 2015 at 12:55:34PM +0100, Julien Grall wrote:
>>> Hi all,
>>>
>>> This small series are the only changes required in Xen in order to run a guest
>>> using 64K page granularity on top of an unmodified Xen.
>>>
>>> I'd like feedback from maintainers tools to know if it might be worth to
>>> introduce a function xc_pagesize() replicating the behavior of getpagesize()
>>> for Xen.
>>>
>>
>> Can we start with documenting the ABI (?) for communicating between
>> guests with different page sizes?
> 
> We should certainly make it clearer what things are in terms of "Xen ABI
> page size" vs "the guest's page size" and other things.
> 
> I think we can commit these two without that though?

Ping? It would be nice to have these 2 patches for Xen 4.5. This is the
only patch necessary in Xen in order to run OS using 64KB page
granularity as DOM0.

Regards,

-- 
Julien Grall

Re: [PATCH 0/2] xen: Allow xen tools to run in guest using 64K page granularity

[Ian Campbell]

On Tue, 2015-07-07 at 13:20 +0100, Julien Grall wrote:
> Hi Ian,
> 
> On 25/06/15 12:23, Ian Campbell wrote:
> > On Thu, 2015-06-25 at 11:21 +0100, Wei Liu wrote:
> >> On Mon, May 11, 2015 at 12:55:34PM +0100, Julien Grall wrote:
> >>> Hi all,
> >>>
> >>> This small series are the only changes required in Xen in order to run a guest
> >>> using 64K page granularity on top of an unmodified Xen.
> >>>
> >>> I'd like feedback from maintainers tools to know if it might be worth to
> >>> introduce a function xc_pagesize() replicating the behavior of getpagesize()
> >>> for Xen.
> >>>
> >>
> >> Can we start with documenting the ABI (?) for communicating between
> >> guests with different page sizes?
> > 
> > We should certainly make it clearer what things are in terms of "Xen ABI
> > page size" vs "the guest's page size" and other things.
> > 
> > I think we can commit these two without that though?
> 
> Ping? It would be nice to have these 2 patches for Xen 4.5. This is the
> only patch necessary in Xen in order to run OS using 64KB page
> granularity as DOM0.

Wei acked the patch at "Thu, 25 Jun 2015 13:58:26 +0100" after the
discussion around the docs which concluded at "Thu, 25 Jun 2015 12:45:49
+0100", IOW I have assumed this Ack to mean he is ok with them going in
with a docs patch to follow.

Hence I have acked them myself and applied.

Please do follow up with the promised doc patch.

Ian.

Re: [PATCH 0/2] xen: Allow xen tools to run in guest using 64K page granularity

[Julien Grall]

Hi Ian,

On 07/07/15 16:19, Ian Campbell wrote:
> On Tue, 2015-07-07 at 13:20 +0100, Julien Grall wrote:
>> Hi Ian,
>>
>> On 25/06/15 12:23, Ian Campbell wrote:
>>> On Thu, 2015-06-25 at 11:21 +0100, Wei Liu wrote:
>>>> On Mon, May 11, 2015 at 12:55:34PM +0100, Julien Grall wrote:
>>>>> Hi all,
>>>>>
>>>>> This small series are the only changes required in Xen in order to run a guest
>>>>> using 64K page granularity on top of an unmodified Xen.
>>>>>
>>>>> I'd like feedback from maintainers tools to know if it might be worth to
>>>>> introduce a function xc_pagesize() replicating the behavior of getpagesize()
>>>>> for Xen.
>>>>>
>>>>
>>>> Can we start with documenting the ABI (?) for communicating between
>>>> guests with different page sizes?
>>>
>>> We should certainly make it clearer what things are in terms of "Xen ABI
>>> page size" vs "the guest's page size" and other things.
>>>
>>> I think we can commit these two without that though?
>>
>> Ping? It would be nice to have these 2 patches for Xen 4.5. This is the
>> only patch necessary in Xen in order to run OS using 64KB page
>> granularity as DOM0.
> 
> Wei acked the patch at "Thu, 25 Jun 2015 13:58:26 +0100" after the
> discussion around the docs which concluded at "Thu, 25 Jun 2015 12:45:49
> +0100", IOW I have assumed this Ack to mean he is ok with them going in
> with a docs patch to follow.

Would it be possible to backport those 2 patches on Xen 4.5 (I don't
think it worth to do it for Xen 4.4)? It's the only changes to allow
Linux using 64KB page granularity running on Xen 4.5.

Regards,

-- 
Julien Grall

Re: [PATCH 0/2] xen: Allow xen tools to run in guest using 64K page granularity

[Ian Campbell]

On Mon, 2015-07-20 at 14:57 +0100, Julien Grall wrote:
> Hi Ian,

This is a tools backport, so needs to be Ian J not me.

> On 07/07/15 16:19, Ian Campbell wrote:
> > On Tue, 2015-07-07 at 13:20 +0100, Julien Grall wrote:
> >> Hi Ian,
> >>
> >> On 25/06/15 12:23, Ian Campbell wrote:
> >>> On Thu, 2015-06-25 at 11:21 +0100, Wei Liu wrote:
> >>>> On Mon, May 11, 2015 at 12:55:34PM +0100, Julien Grall wrote:
> >>>>> Hi all,
> >>>>>
> >>>>> This small series are the only changes required in Xen in order to run a guest
> >>>>> using 64K page granularity on top of an unmodified Xen.
> >>>>>
> >>>>> I'd like feedback from maintainers tools to know if it might be worth to
> >>>>> introduce a function xc_pagesize() replicating the behavior of getpagesize()
> >>>>> for Xen.
> >>>>>
> >>>>
> >>>> Can we start with documenting the ABI (?) for communicating between
> >>>> guests with different page sizes?
> >>>
> >>> We should certainly make it clearer what things are in terms of "Xen ABI
> >>> page size" vs "the guest's page size" and other things.
> >>>
> >>> I think we can commit these two without that though?
> >>
> >> Ping? It would be nice to have these 2 patches for Xen 4.5. This is the
> >> only patch necessary in Xen in order to run OS using 64KB page
> >> granularity as DOM0.
> > 
> > Wei acked the patch at "Thu, 25 Jun 2015 13:58:26 +0100" after the
> > discussion around the docs which concluded at "Thu, 25 Jun 2015 12:45:49
> > +0100", IOW I have assumed this Ack to mean he is ok with them going in
> > with a docs patch to follow.
> 
> Would it be possible to backport those 2 patches on Xen 4.5 (I don't
> think it worth to do it for Xen 4.4)? It's the only changes to allow
> Linux using 64KB page granularity running on Xen 4.5.

On the face of it sounds reasonable to me.