Re: [Xen-devel] XC_PAGE_SIZE or XEN_PAGE_SIZE?

2016-12-02 Thread Oleksandr Andrushchenko

On 12/02/2016 01:53 PM, Andrew Cooper wrote:

On 02/12/16 11:43, Jan Beulich wrote:

On 02.12.16 at 12:20,  wrote:

On 12/02/2016 01:03 PM, Jan Beulich wrote:

On 02.12.16 at 08:49,  wrote:

While working on display protocol I found that there is no(?) common

???_PAGE_SIZE define I can use for both Xen and Linux kernel:

Xen defines XC_PAGE_SIZE which is also used in Linux user-space and

kernel has XEN_PAGE_SIZE, but no XC_PAGE_SIZE.

So, the question is which define should I use?

In the abstract protocol there should be no need for this other
than in comments (as is the case for all other protocols with the
exception of vscsiif, which had a need to define its own
VSCSIIF_PAGE_SIZE), where I think just PAGE_SIZE will be fine.
In the end, frontend and backend are required to agree on a
page size via some side channel anyway, which usually is
achieved by base architecture assumptions (after all both run
on the same physical machine and hence with the same set of
architecture prerequisites). Arguably this is not an optimal model
(namely on architectures supporting varying page sizes), but if
we were to change it we should probably do so for all protocols.

In the implementation you use the manifest constant available: If
your code is in user space, use XC_PAGE_SIZE. In the kernel you'd
obviously use XEN_PAGE_SIZE.

I'll give you an example:
#define XENDISPL_PAGE_SIZE 4096
#define XENDISPL_IN_RING_OFFS (sizeof(struct xendispl_event_page))
#define XENDISPL_IN_RING_SIZE (XENDISPL_PAGE_SIZE - XENDISPL_IN_RING_OFFS)

By this code I define an event ring for async messages from front to back.
This is almost the same as already defined in kbdif and fbif which
define it to 2048
In my case I wanted to rely on page size.

But as said - from an abstract perspective there's no universal
page size here, so I don't see why you want to make one up.

Particularly on ARM, you may have one domain using 4k pages and one
domain using 64k.

This issue has already been fudged once because of a blanket assumption
of the use of 4k pages.

All new work should have care taken to deal cleanly with the problem.

~Andrew

exactly for this reason I am defining

#define XENDISPL_PAGE_SIZE 4096
but I would probably change its name to XENDISPL_RING_SIZE



___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel


Re: [Xen-devel] XC_PAGE_SIZE or XEN_PAGE_SIZE?

2016-12-02 Thread Andrew Cooper
On 02/12/16 11:43, Jan Beulich wrote:
 On 02.12.16 at 12:20,  wrote:
>> On 12/02/2016 01:03 PM, Jan Beulich wrote:
>> On 02.12.16 at 08:49,  wrote:
 While working on display protocol I found that there is no(?) common

 ???_PAGE_SIZE define I can use for both Xen and Linux kernel:

 Xen defines XC_PAGE_SIZE which is also used in Linux user-space and

 kernel has XEN_PAGE_SIZE, but no XC_PAGE_SIZE.

 So, the question is which define should I use?
>>> In the abstract protocol there should be no need for this other
>>> than in comments (as is the case for all other protocols with the
>>> exception of vscsiif, which had a need to define its own
>>> VSCSIIF_PAGE_SIZE), where I think just PAGE_SIZE will be fine.
>>> In the end, frontend and backend are required to agree on a
>>> page size via some side channel anyway, which usually is
>>> achieved by base architecture assumptions (after all both run
>>> on the same physical machine and hence with the same set of
>>> architecture prerequisites). Arguably this is not an optimal model
>>> (namely on architectures supporting varying page sizes), but if
>>> we were to change it we should probably do so for all protocols.
>>>
>>> In the implementation you use the manifest constant available: If
>>> your code is in user space, use XC_PAGE_SIZE. In the kernel you'd
>>> obviously use XEN_PAGE_SIZE.
>> I'll give you an example:
>> #define XENDISPL_PAGE_SIZE 4096
>> #define XENDISPL_IN_RING_OFFS (sizeof(struct xendispl_event_page))
>> #define XENDISPL_IN_RING_SIZE (XENDISPL_PAGE_SIZE - XENDISPL_IN_RING_OFFS)
>>
>> By this code I define an event ring for async messages from front to back.
>> This is almost the same as already defined in kbdif and fbif which 
>> define it to 2048
>> In my case I wanted to rely on page size.
> But as said - from an abstract perspective there's no universal
> page size here, so I don't see why you want to make one up.

Particularly on ARM, you may have one domain using 4k pages and one
domain using 64k.

This issue has already been fudged once because of a blanket assumption
of the use of 4k pages.

All new work should have care taken to deal cleanly with the problem.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel


Re: [Xen-devel] XC_PAGE_SIZE or XEN_PAGE_SIZE?

2016-12-02 Thread Oleksandr Andrushchenko

On 12/02/2016 01:43 PM, Jan Beulich wrote:

On 02.12.16 at 12:20,  wrote:

On 12/02/2016 01:03 PM, Jan Beulich wrote:

On 02.12.16 at 08:49,  wrote:

While working on display protocol I found that there is no(?) common

???_PAGE_SIZE define I can use for both Xen and Linux kernel:

Xen defines XC_PAGE_SIZE which is also used in Linux user-space and

kernel has XEN_PAGE_SIZE, but no XC_PAGE_SIZE.

So, the question is which define should I use?

In the abstract protocol there should be no need for this other
than in comments (as is the case for all other protocols with the
exception of vscsiif, which had a need to define its own
VSCSIIF_PAGE_SIZE), where I think just PAGE_SIZE will be fine.
In the end, frontend and backend are required to agree on a
page size via some side channel anyway, which usually is
achieved by base architecture assumptions (after all both run
on the same physical machine and hence with the same set of
architecture prerequisites). Arguably this is not an optimal model
(namely on architectures supporting varying page sizes), but if
we were to change it we should probably do so for all protocols.

In the implementation you use the manifest constant available: If
your code is in user space, use XC_PAGE_SIZE. In the kernel you'd
obviously use XEN_PAGE_SIZE.

I'll give you an example:
#define XENDISPL_PAGE_SIZE 4096
#define XENDISPL_IN_RING_OFFS (sizeof(struct xendispl_event_page))
#define XENDISPL_IN_RING_SIZE (XENDISPL_PAGE_SIZE - XENDISPL_IN_RING_OFFS)

By this code I define an event ring for async messages from front to back.
This is almost the same as already defined in kbdif and fbif which
define it to 2048
In my case I wanted to rely on page size.

But as said - from an abstract perspective there's no universal
page size here, so I don't see why you want to make one up.

no reason, but my will to have it 4K

Possibly different OSes running in different VMs may not even
have a way to agree on a common value, so you're better of
using some arbitrarily chose value (which still may match the
page size in most commonly used architectures) without trying
to derive is from whatever someone may consider is the page
size.

#define XENDISPL_PAGE_SIZE 4096

If granting access to that space is involved, then referring
to grant page size in a comment may be reasonable (albeit you
will find that nothing there requires it to be 4k either - any
other power of two below 64k should be fine in theory).

Jan


sure

Thank you,
Oleksandr

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel


Re: [Xen-devel] XC_PAGE_SIZE or XEN_PAGE_SIZE?

2016-12-02 Thread Jan Beulich
>>> On 02.12.16 at 12:20,  wrote:
> On 12/02/2016 01:03 PM, Jan Beulich wrote:
> On 02.12.16 at 08:49,  wrote:
>>> While working on display protocol I found that there is no(?) common
>>>
>>> ???_PAGE_SIZE define I can use for both Xen and Linux kernel:
>>>
>>> Xen defines XC_PAGE_SIZE which is also used in Linux user-space and
>>>
>>> kernel has XEN_PAGE_SIZE, but no XC_PAGE_SIZE.
>>>
>>> So, the question is which define should I use?
>> In the abstract protocol there should be no need for this other
>> than in comments (as is the case for all other protocols with the
>> exception of vscsiif, which had a need to define its own
>> VSCSIIF_PAGE_SIZE), where I think just PAGE_SIZE will be fine.
>> In the end, frontend and backend are required to agree on a
>> page size via some side channel anyway, which usually is
>> achieved by base architecture assumptions (after all both run
>> on the same physical machine and hence with the same set of
>> architecture prerequisites). Arguably this is not an optimal model
>> (namely on architectures supporting varying page sizes), but if
>> we were to change it we should probably do so for all protocols.
>>
>> In the implementation you use the manifest constant available: If
>> your code is in user space, use XC_PAGE_SIZE. In the kernel you'd
>> obviously use XEN_PAGE_SIZE.
> I'll give you an example:
> #define XENDISPL_PAGE_SIZE 4096
> #define XENDISPL_IN_RING_OFFS (sizeof(struct xendispl_event_page))
> #define XENDISPL_IN_RING_SIZE (XENDISPL_PAGE_SIZE - XENDISPL_IN_RING_OFFS)
> 
> By this code I define an event ring for async messages from front to back.
> This is almost the same as already defined in kbdif and fbif which 
> define it to 2048
> In my case I wanted to rely on page size.

But as said - from an abstract perspective there's no universal
page size here, so I don't see why you want to make one up.
Possibly different OSes running in different VMs may not even
have a way to agree on a common value, so you're better of
using some arbitrarily chose value (which still may match the
page size in most commonly used architectures) without trying
to derive is from whatever someone may consider is the page
size. If granting access to that space is involved, then referring
to grant page size in a comment may be reasonable (albeit you
will find that nothing there requires it to be 4k either - any
other power of two below 64k should be fine in theory).

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel


Re: [Xen-devel] XC_PAGE_SIZE or XEN_PAGE_SIZE?

2016-12-02 Thread Oleksandr Andrushchenko

On 12/02/2016 01:03 PM, Jan Beulich wrote:

On 02.12.16 at 08:49,  wrote:

While working on display protocol I found that there is no(?) common

???_PAGE_SIZE define I can use for both Xen and Linux kernel:

Xen defines XC_PAGE_SIZE which is also used in Linux user-space and

kernel has XEN_PAGE_SIZE, but no XC_PAGE_SIZE.

So, the question is which define should I use?

In the abstract protocol there should be no need for this other
than in comments (as is the case for all other protocols with the
exception of vscsiif, which had a need to define its own
VSCSIIF_PAGE_SIZE), where I think just PAGE_SIZE will be fine.
In the end, frontend and backend are required to agree on a
page size via some side channel anyway, which usually is
achieved by base architecture assumptions (after all both run
on the same physical machine and hence with the same set of
architecture prerequisites). Arguably this is not an optimal model
(namely on architectures supporting varying page sizes), but if
we were to change it we should probably do so for all protocols.

In the implementation you use the manifest constant available: If
your code is in user space, use XC_PAGE_SIZE. In the kernel you'd
obviously use XEN_PAGE_SIZE.

I'll give you an example:
#define XENDISPL_PAGE_SIZE 4096
#define XENDISPL_IN_RING_OFFS (sizeof(struct xendispl_event_page))
#define XENDISPL_IN_RING_SIZE (XENDISPL_PAGE_SIZE - XENDISPL_IN_RING_OFFS)

By this code I define an event ring for async messages from front to back.
This is almost the same as already defined in kbdif and fbif which 
define it to 2048

In my case I wanted to rely on page size.

Jan




___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel


Re: [Xen-devel] XC_PAGE_SIZE or XEN_PAGE_SIZE?

2016-12-02 Thread Jan Beulich
>>> On 02.12.16 at 08:49,  wrote:
> While working on display protocol I found that there is no(?) common
> 
> ???_PAGE_SIZE define I can use for both Xen and Linux kernel:
> 
> Xen defines XC_PAGE_SIZE which is also used in Linux user-space and
> 
> kernel has XEN_PAGE_SIZE, but no XC_PAGE_SIZE.
> 
> So, the question is which define should I use?

In the abstract protocol there should be no need for this other
than in comments (as is the case for all other protocols with the
exception of vscsiif, which had a need to define its own
VSCSIIF_PAGE_SIZE), where I think just PAGE_SIZE will be fine.
In the end, frontend and backend are required to agree on a
page size via some side channel anyway, which usually is
achieved by base architecture assumptions (after all both run
on the same physical machine and hence with the same set of
architecture prerequisites). Arguably this is not an optimal model
(namely on architectures supporting varying page sizes), but if
we were to change it we should probably do so for all protocols.

In the implementation you use the manifest constant available: If
your code is in user space, use XC_PAGE_SIZE. In the kernel you'd
obviously use XEN_PAGE_SIZE.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel


[Xen-devel] XC_PAGE_SIZE or XEN_PAGE_SIZE?

2016-12-01 Thread Oleksandr Andrushchenko

Hi, all!

While working on display protocol I found that there is no(?) common

???_PAGE_SIZE define I can use for both Xen and Linux kernel:

Xen defines XC_PAGE_SIZE which is also used in Linux user-space and

kernel has XEN_PAGE_SIZE, but no XC_PAGE_SIZE.

So, the question is which define should I use? Or just replace it with

some number, like fbif does:

#define XENFB_OUT_RING_SIZE 2048

Thank you,

Oleksandr


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel