linux-toradex.git/drivers/xen/xenbus, branch v4.4.14

xenbus: Support multiple grants ring with 64KB

2015-10-23T13:20:47+00:00

The PV ring may use multiple grants and expect them to be mapped
contiguously in the virtual memory.

Although, the current code is relying on a Linux page will be mapped to
a single grant. On build where Linux is using a different page size than
the grant (i.e other than 4KB), the grant will always be mapped on the
first 4KB of each Linux page which make the final ring not contiguous in
the memory.

This can be fixed by mapping multiple grant in a same Linux page.

Signed-off-by: Julien Grall 
Signed-off-by: David Vrabel

xen/xenbus: Rename RING_PAGE to RING_GRANT

2015-10-23T13:20:46+00:00

Linux may use a different page size than the size of grant. So make
clear that the order is actually in number of grant.

Signed-off-by: Julien Grall 
Signed-off-by: David Vrabel

xen/xenbus: Use Xen page definition

2015-10-23T13:20:37+00:00

All the ring (xenstore, and PV rings) are always based on the page
granularity of Xen.

Signed-off-by: Julien Grall 
Reviewed-by: David Vrabel 
Reviewed-by: Stefano Stabellini 
Signed-off-by: David Vrabel

xen/balloon: make alloc_xenballoon_pages() always allocate low pages

2015-10-23T13:20:05+00:00

All users of alloc_xenballoon_pages() wanted low memory pages, so
remove the option for high memory.

Signed-off-by: David Vrabel 
Reviewed-by: Daniel Kiper

xen/xenbus: Rename the variable xen_store_mfn to xen_store_gfn

2015-09-08T17:03:54+00:00

The variable xen_store_mfn is effectively storing a GFN and not an MFN.

Signed-off-by: Julien Grall 
Signed-off-by: David Vrabel

xen: Use correctly the Xen memory terminologies

2015-09-08T17:03:49+00:00

Based on include/xen/mm.h [1], Linux is mistakenly using MFN when GFN
is meant, I suspect this is because the first support for Xen was for
PV. This resulted in some misimplementation of helpers on ARM and
confused developers about the expected behavior.

For instance, with pfn_to_mfn, we expect to get an MFN based on the name.
Although, if we look at the implementation on x86, it's returning a GFN.

For clarity and avoid new confusion, replace any reference to mfn with
gfn in any helpers used by PV drivers. The x86 code will still keep some
reference of pfn_to_mfn which may be used by all kind of guests
No changes as been made in the hypercall field, even
though they may be invalid, in order to keep the same as the defintion
in xen repo.

Note that page_to_mfn has been renamed to xen_page_to_gfn to avoid a
name to close to the KVM function gfn_to_page.

Take also the opportunity to simplify simple construction such
as pfn_to_mfn(page_to_pfn(page)) into xen_page_to_gfn. More complex clean up
will come in follow-up patches.

[1] http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=e758ed14f390342513405dd766e874934573e6cb

Signed-off-by: Julien Grall 
Reviewed-by: Stefano Stabellini 
Acked-by: Dmitry Torokhov 
Acked-by: Wei Liu 
Signed-off-by: David Vrabel

xen/xenbus: Don't leak memory when unmapping the ring on HVM backend

2015-08-11T10:05:58+00:00

The commit ccc9d90a9a8b5c4ad7e9708ec41f75ff9e98d61d "xenbus_client:
Extend interface to support multi-page ring" removes the call to
free_xenballooned_pages() in xenbus_unmap_ring_vfree_hvm(), leaking a
page for every shared ring.

Only with backends running in HVM domains were affected.

Signed-off-by: Julien Grall 
Cc: 
Reviewed-by: Boris Ostrovsky 
Reviewed-by: Wei Liu 
Signed-off-by: David Vrabel

xen/xenbus: client: Fix call of virt_to_mfn in xenbus_grant_ring

2015-06-17T15:15:10+00:00

virt_to_mfn should take a void* rather an unsigned long. While it
doesn't really matter now, it would throw a compiler warning later when
virt_to_mfn will enforce the type.

At the same time, avoid to compute new virtual address every time in the
loop and directly increment the parameter as we don't use it later.

Signed-off-by: Julien Grall 
Reviewed-by: David Vrabel 
Cc: Wei Liu 
Cc: Konrad Rzeszutek Wilk 
Cc: Boris Ostrovsky 
Signed-off-by: David Vrabel

xen: Include xen/page.h rather than asm/xen/page.h

2015-06-17T15:14:18+00:00

Using xen/page.h will be necessary later for using common xen page
helpers.

As xen/page.h already include asm/xen/page.h, always use the later.

Signed-off-by: Julien Grall 
Reviewed-by: David Vrabel 
Cc: Stefano Stabellini 
Cc: Ian Campbell 
Cc: Wei Liu 
Cc: Konrad Rzeszutek Wilk 
Cc: Boris Ostrovsky 
Cc: netdev@vger.kernel.org
Signed-off-by: David Vrabel

xenbus: avoid uninitialized variable warning

2015-05-28T11:23:12+00:00

Older compilers don't recognize that "v" can't be used uninitialized;
other code using hvm_get_parameter() zeros the value too, so follow
suit here.

Signed-off-by: Jan Beulich 
Signed-off-by: David Vrabel