From: Julien Grall
Since commit b764915 "xen-blkfront: use a different scatterlist for each
request", biovec has been replaced by scatterlist when copying back the
data during a completion request.
Signed-off-by: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Boris Ostrovsky
Cc: David
From: Julien Grall
Make the code less confusing to read now that Linux may not have the
same page size as Xen.
Signed-off-by: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Roger Pau Monné
---
drivers/block/xen-blkback/blkback.c | 10 +-
drivers/block/xen-blkback/common.h | 2 +-
2
SPP was used by the grant table v2 code which has been removed in
commit 438b33c7145ca8a5131a30c36d8f59bce119a19a "xen/grant-table:
remove support for V2 tables".
Signed-off-by: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Boris Ostrovsky
Cc: David Vrabel
---
drivers/xen/grant-table.
rx->status is an int16_t, print it using %d rather than %u in order to
have a meaningful value when the field is negative.
Signed-off-by: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Boris Ostrovsky
Cc: David Vrabel
Cc: net...@vger.kernel.org
---
drivers/net/xen-netfront.c | 2 +-
1 f
with multiple
grant. It will require some care with the {Set,Clear}ForeignPage macro.
Note that no changes has been made in the x86 code because both Linux
and Xen will only use 4KB page granularity.
Signed-off-by: Julien Grall
Cc: Stefano Stabellini
Cc: Russell King
Cc: Konrad Rzeszutek Wilk
Cc: Boris
will have
to split the Linux page in 4K chunk before asking Xen to add/remove the
frame from the guest.
Note that this can work on any page granularity assuming it's a multiple
of 4K.
Signed-off-by: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Boris Ostrovsky
Cc: David Vrabel
Cc: Wei Liu
on the grant table
code.
Note that the grant table code is allocating a Linux page per grant
which will result to waste 6OKB for every grant when Linux is using 64KB
page granularity. This could be improved by sharing the page between
multiple grants.
Signed-off-by: Julien Grall
Cc: Konrad
on the grant table code.
Note that we allocate a Linux page for each rx skb but only the first
4KB is used. We may improve the memory usage by extending the size of
the rx skb.
Signed-off-by: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Boris Ostrovsky
Cc: David Vrabel
Cc: net...@vger.kernel.org
The xenstore ring is always based on the page granularity of Xen.
Signed-off-by: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Boris Ostrovsky
Cc: David Vrabel
---
drivers/xen/xenbus/xenbus_probe.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/xen/xenbus
With 64KB page granularity support in Linux, a page will be split accross
multiple MFN (Xen is using 4KB page granularity). Thoses MFNs may not be
contiguous.
With the offset in the page, the helper will be able to know which MFN
the driver needs to retrieve.
Signed-off-by: Julien Grall
Cc
From: Julien Grall
The PV block protocol is using 4KB page granularity. The goal of this
patch is to allow a Linux using 64KB page granularity using block
device on a non-modified Xen.
The block API is using segment which should at least be the size of a
Linux page. Therefore, the driver
chunk). That would require more care when we fail to expand the
event channel.
Signed-off-by: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Boris Ostrovsky
Cc: David Vrabel
---
drivers/xen/events/events_base.c | 2 +-
drivers/xen/events/events_fifo.c | 2 +-
2 files changed, 2 insertions(+), 2
The console ring is always based on the page granularity of Xen.
Signed-off-by: Julien Grall
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
Cc: David Vrabel
Cc: Stefano Stabellini
Cc: Boris Ostrovsky
Cc: linuxppc-...@lists.ozlabs.org
---
drivers/tty/hvc/hvc_xen.c | 6 +++---
1 file changed, 3
for (I have limited knowledge on the network driver).
Signed-off-by: Julien Grall
Cc: Ian Campbell
Cc: Wei Liu
Cc: net...@vger.kernel.org
---
Improvement such as support of 64KB grant is not taken into
consideration in this patch because we have the requirement to run a
Linux using 64KB pages
will have
to map multiple Xen PFN in a single Linux page.
Note that this solution works on page granularity which is a multiple of
4KB.
Signed-off-by: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Boris Ostrovsky
Cc: David Vrabel
---
drivers/xen/privcmd.c | 8 +---
drivers/xen/xlate_mmu.c
page even though only the
first 4KB is used. I don't think this is really important for now as it
helps to have the pointer 4KB aligned (XENMEM_add_to_physmap is taking a
Xen PFN).
Signed-off-by: Julien Grall
Cc: Stefano Stabellini
Cc: Russell King
---
arch/arm/include/asm/xen/page.h | 12
When Linux is using 64K page granularity, every page will be slipt in
multiple non-contiguous 4K MFN.
I'm not sure how to handle efficiently the check to know whether we can
merge 2 biovec with a such case. So for now, always says that biovec are
not mergeable.
Signed-off-by: Julien Grall
Cc
definition. They have exactly the same name but prefixed with
XEN_/xen_ prefix.
Also modify page_to_pfn to use new Xen page definition.
Signed-off-by: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Boris Ostrovsky
Cc: David Vrabel
---
include/xen/page.h | 19 ++-
1 file changed, 18
Hi Wei,
Thanks you for the review.
On 15/05/15 03:35, Wei Liu wrote:
> On Thu, May 14, 2015 at 06:01:01PM +0100, Julien Grall wrote:
>> The PV network protocol is using 4KB page granularity. The goal of this
>> patch is to allow a Linux using 64KB page granularity working as a
>
Hi Wei,
On 15/05/15 16:31, Wei Liu wrote:
> On Fri, May 15, 2015 at 01:35:42PM +0100, Julien Grall wrote:
>> On 15/05/15 03:35, Wei Liu wrote:
>>> On Thu, May 14, 2015 at 06:01:01PM +0100, Julien Grall wrote:
>>>> The PV network protocol is using 4KB page granularit
Hi David,
On 15/05/15 16:45, David Vrabel wrote:
> On 14/05/15 18:00, Julien Grall wrote:
>> Hi all,
>>
>> ARM64 Linux is supporting both 4KB and 64KB page granularity. Although, Xen
>> hypercall interface and PV protocol are always based on 4KB page granularity.
>&g
goto fail;
>> }
>> grefs[i] = err;
>> +
>> +vaddr = (char *)vaddr + PAGE_SIZE;
>
> You don't need the cast here since vaddr is a void *.
Arithmetic on void pointer is a GCC extension [1]. I wasn't sure what is
the Linux pol
Hi Boris,
On 15/05/15 16:54, Boris Ostrovsky wrote:
> On 05/14/2015 01:00 PM, Julien Grall wrote:
>> When Linux is using 64K page granularity, every page will be slipt in
>> multiple non-contiguous 4K MFN.
>>
>> I'm not sure how to handle efficiently the check to kno
Hi David,
On 19/05/15 14:57, David Vrabel wrote:
> On 14/05/15 18:00, Julien Grall wrote:
>> With 64KB page granularity support in Linux, a page will be split accross
>> multiple MFN (Xen is using 4KB page granularity). Thoses MFNs may not be
>> contiguous.
>>
>
Hi David,
On 19/05/15 14:59, David Vrabel wrote:
> On 14/05/15 18:00, Julien Grall wrote:
>> The xenstore ring is always based on the page granularity of Xen.
> [...]
>> --- a/drivers/xen/xenbus/xenbus_probe.c
>> +++ b/drivers/xen/xenbus/xenbus_probe.c
>> @@ -713
Hi,
On 18/05/2015 13:54, Wei Liu wrote:
On Mon, May 18, 2015 at 01:11:26PM +0100, Julien Grall wrote:
On 15/05/15 16:31, Wei Liu wrote:
On Fri, May 15, 2015 at 01:35:42PM +0100, Julien Grall wrote:
On 15/05/15 03:35, Wei Liu wrote:
On Thu, May 14, 2015 at 06:01:01PM +0100, Julien Grall
Hi David,
On 20/08/15 10:51, David Vrabel wrote:
> On 07/08/15 17:46, Julien Grall wrote:
>> Currently, a grant is always based on the Xen page granularity (i.e
>> 4KB). When Linux is using a different page granularity, a single page
>> will be split between multiple grants.
Hi David,
On 20/08/15 10:55, David Vrabel wrote:
> On 07/08/15 17:46, Julien Grall wrote:
>> The console ring is always based on the page granularity of Xen.
> [...]
>> --- a/drivers/tty/hvc/hvc_xen.c
>> +++ b/drivers/tty/hvc/hvc_xen.c
>> @@ -230,7 +230,7 @@ static
On 20/08/15 10:59, David Vrabel wrote:
> On 07/08/15 17:46, Julien Grall wrote:
>> For ARM64 guests, Linux is able to support either 64K or 4K page
>> granularity. Although, the hypercall interface is always based on 4K
>> page granularity.
>>
>> With 64
On 20/08/15 09:10, Roger Pau Monné wrote:
> Hello,
Hi,
> I have some comments regarding the commit message, IMHO it would be good
> that a native English speaker reviews it too.
>
> El 07/08/15 a les 18.46, Julien Grall ha escrit:
>> The PV block protocol is using 4KB page
multiple xen_pfn, so we want to get
the next xen_pfn for the next iteration.
Regards,
--
Julien Grall
--
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/major
vice_ functions for determining mac/phy"
Signed-off-by: Julien Grall
Cc: Jeremy Linton
Cc: David S. Miller
---
Cc: Greg Kroah-Hartman
Cc: net...@vger.kernel.org
---
drivers/base/property.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/base/prope
uest allocation and freeing.
>
> Reported-by: Julien Grall
> Signed-off-by: Roger Pau Monné
> Cc: Julien Grall
> Cc: Konrad Rzeszutek Wilk
> Cc: Boris Ostrovsky
> Cc: David Vrabel
> Cc: xen-de...@lists.xenproject.org
The patch is fixing my problem when using UEF
On 07/09/15 07:07, Bob Liu wrote:
> Hi Julien,
Hi Bob,
> On 09/04/2015 09:51 PM, Julien Grall wrote:
>> Hi Roger,
>>
>> On 04/09/15 11:08, Roger Pau Monne wrote:
>>> Request allocation has been moved to connect_ring, which is called every
>>> time
They are not used in common code expect in one place in balloon.c which is
only compiled when Linux is using PV MMU. It's not the case on ARM.
Rather than worrying how to handle the 64KB case, drop them.
Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
---
Cc: Russell King
to copy
data from persistent grant or indirect grant. Avoid to set it for other
use case as it will have no meaning given the page will be split in
multiple grant.
Provide 2 functions, to setup indirect grant, the other for bio page.
Signed-off-by: Julien Grall
Acked-by: Roger Pau Monné
---
Cc
definition. They have exactly the same name but prefixed with
XEN_/xen_ prefix.
Also modify xen_page_to_gfn to use new Xen page definition.
Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
---
Cc: Konrad Rzeszutek Wilk
Cc: Boris Ostrovsky
Cc: David Vrabel
Changes in v4
The skb doesn't change within the function. Therefore it's only
necessary to check if we need GSO once at the beginning.
Signed-off-by: Julien Grall
Acked-by: Wei Liu
---
Cc: Ian Campbell
Cc: net...@vger.kernel.org
Changes in v4:
- Add Wei's acked
Changes in v2
the compilation. Furthermore, only definition in
interface/grant_table.h is required.
Signed-off-by: Julien Grall
Reviewed-by: David Vrabel
Reviewed-by: Stefano Stabellini
---
Cc: Konrad Rzeszutek Wilk
Cc: Boris Ostrovsky
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin&qu
which result
to page_mfn not being defined when necessary.
Signed-off-by: Julien Grall
Reviewed-by: David Vrabel
Reviewed-by: Stefano Stabellini
---
Cc: Konrad Rzeszutek Wilk
Cc: Boris Ostrovsky
Changes in v3:
- Rename gnttab_page_grant_foreign_access_ref
-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
---
Cc: Konrad Rzeszutek Wilk
Cc: Boris Ostrovsky
Cc: David Vrabel
There is some ideas to check whether two biovec could be merged
(see [1]) but it's not critical and can be consider as a performance
improvement.
Changes
)
Julien Grall (20):
A net/xen-netback: xenvif_gop_frag_copy: move GSO check out of the loop
A arm/xen: Drop pte_mfn and mfn_pte
A M L xen: Add Xen specific page definition
A M xen/grant: Introduce helpers to split a page into grant
A xen/grant: Add helper
All the usage of the field pfn are done using the same idiom:
pfn_to_page(grant->pfn)
This will return always the same page. Store directly the page in the
grant to clean up the code.
Signed-off-by: Julien Grall
Acked-by: Roger Pau Monné
Reviewed-by: Stefano Stabellini
---
Cc: Kon
execution path, separate
the function in 2. This will also remove one level of tabulation.
Signed-off-by: Julien Grall
Reviewed-by: Roger Pau Monné
---
Cc: Konrad Rzeszutek Wilk
Cc: Boris Ostrovsky
Cc: David Vrabel
Roger, if you really want if can drop the else clause
will have
to map multiple Xen PFN in a single Linux page.
Note that this solution works on page granularity which is a multiple of
4KB.
Signed-off-by: Julien Grall
Reviewed-by: David Vrabel
---
Cc: Konrad Rzeszutek Wilk
Cc: Boris Ostrovsky
I kept the hypercall arguments in remap_data
The console ring is always based on the page granularity of Xen.
Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
---
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
Cc: David Vrabel
Cc: Boris Ostrovsky
Cc: linuxppc-...@lists.ozlabs.org
Changes in v4:
- The ring is always 4K
chunk). That would require more care when we fail to expand the
event channel.
Signed-off-by: Julien Grall
Reviewed-by: David Vrabel
Reviewed-by: Stefano Stabellini
---
Cc: Konrad Rzeszutek Wilk
Cc: Boris Ostrovsky
Note I haven't updated the suggestion to reduce the memory waste
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
---
Cc: Konrad Rzeszutek Wilk
Cc: Boris Ostrovsky
Changes in v3:
- Fix errors reported by checkpatch.pl
with multiple
grant. It will require some care with the {Set,Clear}ForeignPage macro.
Note that no changes has been made in the x86 code because both Linux
and Xen will only use 4KB page granularity.
Signed-off-by: Julien Grall
Reviewed-by: David Vrabel
Reviewed-by: Stefano Stabellini
---
Cc: Stefano
on the grant table
code.
Note that the grant table code is allocating a Linux page per grant
which will result to waste 6OKB for every grant when Linux is using 64KB
page granularity. This could be improved by sharing the page between
multiple grants.
Signed-off-by: Julien Grall
Acked-by: "
of the
extent_order field to directly allocate/free chunk of the Linux page
size.
Note that PVMMU is only used for PV guest (which is x86) and the page
granularity is always 4KB. Some BUILD_BUG_ON has been added to ensure
that because the code has not been modified.
Signed-off-by: Julien Grall
---
Cc
on the grant table code.
Signed-off-by: Julien Grall
---
Cc: Ian Campbell
Cc: Wei Liu
Cc: net...@vger.kernel.org
Improvement such as support of 64KB grant is not taken into
consideration in this patch because we have the requirement to run a
Linux using 64KB pages on a non-modified Xen.
Note
on the grant table code.
Note that we allocate a Linux page for each rx skb but only the first
4KB is used. We may improve the memory usage by extending the size of
the rx skb.
Signed-off-by: Julien Grall
Reviewed-by: David Vrabel
---
Cc: Konrad Rzeszutek Wilk
Cc: Boris Ostrovsky
Cc: net
with 64KB page granularity).
Furthermore, in the case of persistent grants we allocate one Linux page
per grant although only the first 4KB of the page will be effectively
in use. This could be improved by sharing the page with multiple grants.
Signed-off-by: Julien Grall
Acked-by: Roger Pau Monné
page even though only the
first 4KB is used. I don't think this is really important for now as it
helps to have the pointer 4KB aligned (XENMEM_add_to_physmap is taking a
Xen PFN).
Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
---
Cc: Russell King
Stefano, I've dropped your
latest
linus' master.
> On Mon, Sep 07, 2015 at 04:33:56PM +0100, Julien Grall wrote:
>> The PV network protocol is using 4KB page granularity. The goal of this
>> patch is to allow a Linux using 64KB page granularity working as a
>> network backend on a non-modified Xen.
default IRQ domain to allow for GSI registration and GSI to IRQ
>* number translation (see acpi_register_gsi() and acpi_gsi_to_irq()).
> diff --git a/include/linux/irqchip/arm-gic.h b/include/linux/irqchip/arm-gic.h
> index 9de976b..b1533c0 100644
> --- a/include/linux/irqchip/arm-gic
by itself (UART, virtual GIC...).
So we would need to modify the FreeBSD data structure to pass the new
DT/ACPI. Does the metadata are standardize? I.e is it stable from
accross FreeBSD version?
Anyway, I'd like to avoid any FreeBSD specific code in Xen, and even any
OS specific code in Xen. It's
On 10/09/15 13:05, Roger Pau Monné wrote:
> El 10/09/15 a les 13.48, Julien Grall ha escrit:
>> On 10/09/15 12:32, Andrew Turner wrote:
>>> On Thu, 10 Sep 2015 16:41:56 +0800
>>> Shannon Zhao wrote:
>>>
>>>> From: Shannon Zhao
>>
With 64KB page granularity support, the frame number will be different.
It will be easier to modify the behavior in a single place rather than
in each caller.
Signed-off-by: Julien Grall
---
Cc: Stefano Stabellini
Cc: Russell King
Cc: Konrad Rzeszutek Wilk
Cc: Boris Ostrovsky
Cc: David
minimal because we only need to check the first Xen PFN.
Note that it may be possible to optimize the function
check_page_physically_contiguous to avoid looping over every Xen PFN
for local memory. Although I will let this optimization for a follow-up.
Signed-off-by: Julien Grall
Cc: Stefano
Rzeszutek Wilk
Cc: Boris Ostrovsky
Cc: David Vrabel
Julien Grall (2):
xen/swiotlb: Pass addresses rather than frame numbers to
xen_arch_need_swiotlb
xen/swiotlb: Add support for 64KB page granularity
arch/arm/include/asm/xen/page-coherent.h | 26 ---
arch/arm/include/asm
On 10/09/15 10:54, Marc Zyngier wrote:
> Hi Julian,
Hi Marc,
> On 09/09/15 20:23, Julien Grall wrote:
>> Hi,
>>
>> I've been trying the latest linus/master (a794b4f), which include this
>> patch, as baremetal kernel on X-gene. This is failing on early boot
&g
On 10/09/15 17:30, Marc Zyngier wrote:
> On 10/09/15 17:23, Julien Grall wrote:
>> On 10/09/15 10:54, Marc Zyngier wrote:
>
> [...]
>
>>> In the meantime, can you give the following patch a shot? My Mustang is
>>> wired to a 4kB CPU interface, so I'll need y
On 11/09/2015 11:54, Ian Campbell wrote:
On Thu, 2015-09-10 at 17:23 +0100, Julien Grall wrote:
I applied the two patches on top of linus/master and I'm able to boot
correctly on X-gene. Thank you!
Perhaps we should replicate this approach in Xen and get rid
On 11/09/15 12:09, Marc Zyngier wrote:
> On 11/09/15 11:59, Julien Grall wrote:
>>
>>
>> On 11/09/2015 11:54, Ian Campbell wrote:
>>> On Thu, 2015-09-10 at 17:23 +0100, Julien Grall wrote:
>>>> I applied the two patches on top of linus/master and I'm ab
ations, so the change
is only arm32 specific.
Reported-by: Riku Voipio
Signed-off-by: Julien Grall
---
Cc: Stefano Stabellini
Cc: Russell King
ARM64 doesn't seem to have priviledge no-access support yet so there
is nothing to do for now.
I haven't look x86 at all.
---
arch/arm/xe
On 11/09/15 15:29, Ian Campbell wrote:
> On Fri, 2015-09-11 at 15:16 +0100, Julien Grall wrote:
>> When Xen is copyin data to/from the guest it will check if the kernel
>
> "copying"
>
>> has the right to do the access. If not, the hypercall will return a
On 11/09/15 15:55, Ian Campbell wrote:
> On Fri, 2015-09-11 at 15:45 +0100, Julien Grall wrote:
>> On 11/09/15 15:29, Ian Campbell wrote:
>>> On Fri, 2015-09-11 at 15:16 +0100, Julien Grall wrote:
>>>> When Xen is copyin data to/from the guest it will check
On 11/09/15 16:25, Russell King - ARM Linux wrote:
> On Fri, Sep 11, 2015 at 03:56:38PM +0100, Julien Grall wrote:
>> Well, we can't assume that the function will be called with uaccess
>> disabled.
>
> Please explain your reasoning.
I think I was confused about the usage
I won't fix this one.
All the others will be fixed on the next version.
Regards,
--
Julien Grall
--
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/
ations, so the change
is only arm32 specific.
Reported-by: Riku Voipio
Signed-off-by: Julien Grall
---
Cc: Stefano Stabellini
Cc: Russell King
Changes in v2:
- Directly enable/disable the user space access in assembly
- Typoes
ARM64 doesn't seem to have priviledge
On 11/09/15 18:00, Russell King - ARM Linux wrote:
> On Fri, Sep 11, 2015 at 05:25:59PM +0100, Julien Grall wrote:
>> +/*
>> + * Privcmd calls are issued by the userspace. We need to allow the
>> + * kernel to access the userspace memory before
On 11/09/15 18:32, Julien Grall wrote:
> On 11/09/15 18:00, Russell King - ARM Linux wrote:
>> On Fri, Sep 11, 2015 at 05:25:59PM +0100, Julien Grall wrote:
>>> + /*
>>> +* Privcmd calls are issued by the userspace. We need to allow the
>>> +* kernel t
On 11/09/15 18:00, Russell King - ARM Linux wrote:
> On Fri, Sep 11, 2015 at 05:25:59PM +0100, Julien Grall wrote:
>> +/*
>> + * Privcmd calls are issued by the userspace. We need to allow the
>> + * kernel to access the userspace memory before
The code to get a request is always the same. Therefore we can factorize
it in a single function.
Signed-off-by: Julien Grall
---
Cc: Konrad Rzeszutek Wilk
Cc: "Roger Pau Monné"
Cc: Boris Ostrovsky
Cc: David Vrabel
---
drivers/block/xen-blkfront.c | 30 +++
Rzeszutek Wilk
Cc: "Roger Pau Monné"
Cc: Boris Ostrovsky
Cc: David Vrabel
Julien Grall (2):
block/xen-blkfront: Introduce blkif_ring_get_request
block/xen-blkfront: Handle non-indirect grant with 64KB pages
drivers/block/xen-blkfront.c | 229
e able to
support directly any change in the block framework that lower down the
mimimal size of a request.
[1] http://lists.xen.org/archives/html/xen-devel/2015-08/msg02200.html
Signed-off-by: Julien Grall
---
Cc: Konrad Rzeszutek Wilk
Cc: "Roger Pau Monné"
Cc: Boris Ostrovsky
Hi,
A quick update on the TODO.
On 07/09/15 16:33, Julien Grall wrote:
> ARM64 Linux is supporting both 4KB and 64KB page granularity. Although, Xen
> hypercall interface and PV protocol are always based on 4KB page granularity.
>
> Any attempt to boot a Linux guest with 64KB p
en plumbed. I would
make sure that XEN_SYMS is not enabled for ARM maybe adding the line
below in the kconfig?
depends on X86 && XEN_DOM0 && XENFS
Regards,
--
Julien Grall
--
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/
All the caller of xen_tmem_{get,put}_page have a struct page * in hand
and call pfn_to_gfn for the only benefits of these 2 functions.
Rather than passing the pfn in parameter, pass directly the page and use
directly xen_page_to_gfn.
Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
to rename pfn_to_mfn to a suitable
name.
Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
---
Cc: Russell King
Cc: linux-arm-ker...@lists.infradead.org
Changes in v3:
- Typoes in the commit message
- Add Stefano's reviewed-by
---
arch/arm/include/asm/xen/page.h
The PV driver xen-fbfront is only dealing with GFN and not MFN. Rename
all the occurence of MFN to GFN.
Also take the opportunity to replace to usage of pfn_to_gfn by
xen_page_to_gfn.
Signed-off-by: Julien Grall
Reviewed-by: David Vrabel
---
Cc: Jean-Christophe Plagniol-Villard
Cc: Tomi
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
is only used in PV specific code.
Therefore we should never call the function.
Add a BUG() in this helper and drop all the others.
Signed-off-by: Julien Grall
Acked-by: Stefano Stabellini
---
Cc: Russell King
Cc: linux-arm-ker...@lists.infradead.org
Changes in v2:
- Typoes
The variable xen_store_mfn is effectively storing a GFN and not an MFN.
Signed-off-by: Julien Grall
---
Cc: Konrad Rzeszutek Wilk
Cc: Boris Ostrovsky
Cc: David Vrabel
I think that the assignation of xen_start_info in
xenstored_local_init is pointless. Although I haven't drop it just
foreign change has been left unchanged
given that the userspace is using it. Nonetheless, add a comment to
explain the expected value within the "mfn" field.
Signed-off-by: Julien Grall
Reviewed-by: David Vrabel
---
Cc: Stefano Stabellini
Cc: Russell King
Cc: Konrad Rzeszutek Wilk
nel.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-s...@vger.kernel.org
Cc: net...@vger.kernel.org
Cc: "Roger Pau Monné"
Cc: Russell King
Cc: Stefano Stabellini
Cc: Thomas Gleixner
Cc: Tomi Valkeinen
Cc: Wei Liu
Cc: x...@kernel.org
Julien Grall (9):
arm/xen: Remove helpers which are
HVM_PARAM_CONSOLE_PFN is used to retrieved the console PFN for HVM
guest. It returns a PFN (aka GFN) and not a MFN.
Furthermore, use directly virt_to_gfn for both PV and HVM domain rather
than doing a special case for each of the them.
Signed-off-by: Julien Grall
Reviewed-by: David Vrabel
foreign page and
another using Linux memory.
Lastly, the helper mfn_to_local_pfn has been renamed to bfn_to_local_pfn
given that the only usage was in swiotlb.
Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
---
Cc: Russell King
Cc: Konrad Rzeszutek Wilk
Cc: Boris Ostrovsky
Cc
They are not used in common code expect in one place in balloon.c which is
only compiled when Linux is using PV MMU. It's not the case on ARM.
Rather than worrying how to handle the 64KB case, drop them.
Signed-off-by: Julien Grall
---
Stefano Stabellini
Russell King
Changes in v3
-off-by: Julien Grall
---
Cc: Konrad Rzeszutek Wilk
Cc: Boris Ostrovsky
Cc: David Vrabel
There is some ideas to check whether two biovec could be merged
(see [1]) but it's not critical and can be consider as a performance
improvement.
Changes in v3:
- Update commit
which result
to page_mfn not being defined when necessary.
Signed-off-by: Julien Grall
Reviewed-by: David Vrabel
Reviewed-by: Stefano Stabellini
---
Cc: Konrad Rzeszutek Wilk
Cc: Boris Ostrovsky
Changes in v3:
- Rename gnttab_page_grant_foreign_access_ref
to copy
data from persistent grant or indirect grant. Avoid to set it for other
use case as it will have no meaning given the page will be split in
multiple grant.
Provide 2 functions, to setup indirect grant, the other for bio page.
Signed-off-by: Julien Grall
---
Cc: Konrad Rzeszutek Wilk
Cc
execution path, separate
the function in 2. This will also remove one level of tabulation.
Signed-off-by: Julien Grall
Reviewed-by: Roger Pau Monné
---
Cc: Konrad Rzeszutek Wilk
Cc: Boris Ostrovsky
Cc: David Vrabel
Roger, if you really want if can drop the else clause
be found here:
git://xenbits.xen.org/people/julieng/linux-arm.git branch xen-64k-v3
Comments, suggestions are welcomed.
Sincerely yours,
Cc: david.vra...@citrix.com
Cc: konrad.w...@oracle.com
Cc: boris.ostrov...@oracle.com
Cc: wei.l...@citrix.com
Cc: roger@citrix.com
Julien Grall (20):
net/xen
The skb doesn't change within the function. Therefore it's only
necessary to check if we need GSO once at the beginning.
Signed-off-by: Julien Grall
---
Cc: Ian Campbell
Cc: Wei Liu
Cc: net...@vger.kernel.org
Changes in v2:
- Patch added
---
drivers/net/xen-netback/netback.c
the compilation. Furthermore, only definition in
interface/grant_table.h was required.
Signed-off-by: Julien Grall
---
Cc: Konrad Rzeszutek Wilk
Cc: Boris Ostrovsky
Cc: David Vrabel
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Changes in v3:
-
All the usage of the field pfn are done using the same idiom:
pfn_to_page(grant->pfn)
This will return always the same page. Store directly the page in the
grant to clean up the code.
Signed-off-by: Julien Grall
Acked-by: Roger Pau Monné
Reviewed-by: Stefano Stabellini
---
Cc: Kon
definition. They have exactly the same name but prefixed with
XEN_/xen_ prefix.
Also modify xen_page_to_gfn to use new Xen page definition.
Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
---
Cc: Konrad Rzeszutek Wilk
Cc: Boris Ostrovsky
Cc: David Vrabel
Changes in v3
901 - 1000 of 1315 matches
Mail list logo
