)
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 <julien.gr...@citrix.com>
Acked-by: Roger Pau Monné <roger...
the compilation. Furthermore, only definition in
interface/grant_table.h is required.
Signed-off-by: Julien Grall <julien.gr...@citrix.com>
Reviewed-by: David Vrabel <david.vra...@citrix.com>
Reviewed-by: Stefano Stabellini <stefano.stabell...@eu.citrix.com>
---
Cc: Konrad Rzeszu
which result
to page_mfn not being defined when necessary.
Signed-off-by: Julien Grall <julien.gr...@linaro.org>
Reviewed-by: David Vrabel <david.vra...@citrix.com>
Reviewed-by: Stefano Stabellini <stefano.stabell...@eu.citrix.com>
---
Cc: Konrad Rzeszutek Wilk <konrad.w...@
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 <julien.gr...@citrix.com>
Reviewed-by: Stefano Stab
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 <julien.gr...@citrix.com>
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 <julien.gr...@citrix.com>
Reviewed-by: Stefano Stabellini <stefano.stabell...@eu.citrix.com>
---
Cc: Konrad Rz
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 <julien.gr...@citrix.com>
Acked-by: Wei Liu <wei.l...@citrix.com>
---
Cc: Ian Campbell <ian.campb...@citrix.com>
Cc: net.
The console ring is always based on the page granularity of Xen.
Signed-off-by: Julien Grall <julien.gr...@citrix.com>
Reviewed-by: Stefano Stabellini <stefano.stabell...@eu.citrix.com>
---
Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
Cc: Jiri Slaby <jsl...@suse
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 <julien.gr...@citrix.com>
Reviewed-by: David Vrabel <david.vra...@citrix.com>
---
Cc: Konrad Rzeszutek Wilk <konrad.w...
execution path, separate
the function in 2. This will also remove one level of tabulation.
Signed-off-by: Julien Grall <julien.gr...@citrix.com>
Reviewed-by: Roger Pau Monné <roger@citrix.com>
---
Cc: Konrad Rzeszutek Wilk <konrad.w...@oracle.com>
Cc: Boris Ostrovsky <boris
on the grant table code.
Signed-off-by: Julien Grall <julien.gr...@citrix.com>
---
Cc: Ian Campbell <ian.campb...@citrix.com>
Cc: Wei Liu <wei.l...@citrix.com>
Cc: net...@vger.kernel.org
Improvement such as support of 64KB grant is not taken into
consideration in this pat
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 <julien.gr...@citrix.com>
Reviewed-by: David Vrabel <david.vra...@citrix.com>
---
Cc: Konr
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 <julien.gr...@citrix.
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 <julien.gr...@citrix.com>
Reviewed-by: Stefano Stabellini <stefan
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 <julien
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
chunk). That would require more care when we fail to expand the
event channel.
Signed-off-by: Julien Grall <julien.gr...@citrix.com>
Reviewed-by: David Vrabel <david.vra...@citrix.com>
Reviewed-by: Stefano Stabellini <stefano.stabell...@citrix.com>
---
Cc: Konrad Rzeszu
All the ring (xenstore, and PV rings) are always based on the page
granularity of Xen.
Signed-off-by: Julien Grall <julien.gr...@citrix.com>
Reviewed-by: David Vrabel <david.vra...@citrix.com>
Reviewed-by: Stefano Stabellini <stefano.stabell...@eu.citrix.com>
---
Cc: Kon
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 <julien.gr...@citrix.com>
Reviewed-by: David Vrabel <david.vra...@c
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.
vice_ functions for determining mac/phy"
Signed-off-by: Julien Grall <julien.gr...@citrix.com>
Cc: Jeremy Linton <jeremy.lin...@arm.com>
Cc: David S. Miller <da...@davemloft.net>
---
Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
Cc: net...@vger.kernel.org
---
drivers
eeBSD specific code in Xen, and even any
OS specific code in Xen. It's better if we keep a common interface for
everyone.
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/
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 <julien
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 <julien.gr...@citrix.com>
---
Cc: Stefano Stabellini <stefano.stabell...@eu.citrix.com>
Cc: Russ
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 <zhaoshengl...@huawei.com> wrote:
>>>
>&g
Rzeszutek Wilk <konrad.w...@oracle.com>
Cc: Boris Ostrovsky <boris.ostrov...@oracle.com>
Cc: David Vrabel <david.vra...@citrix.com>
Julien Grall (2):
xen/swiotlb: Pass addresses rather than frame numbers to
xen_arch_need_swiotlb
xen/swiotlb: Add support for 64KB page gran
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 12/09/2015 10:46, Bob Liu wrote:
Hi Julien,
Hi Bob,
On 09/12/2015 03:31 AM, Julien Grall wrote:
Hi all,
This is a follow-up on the previous discussion [1] related to guest using 64KB
page granularity not booting with backend using non-indirect grant.
This has been successly tested
On 14/09/15 12:04, Roger Pau Monné wrote:
> Hello,
>
> El 14/09/15 a les 12.40, Julien Grall ha escrit:
>> Hi Roger,
>>
>> On 14/09/15 09:56, Roger Pau Monné wrote:
>>> El 07/09/15 a les 17.33, Julien Grall ha escrit:
>>>> Hi all,
>>&g
Hi Roger,
On 14/09/15 09:56, Roger Pau Monné wrote:
> El 07/09/15 a les 17.33, Julien Grall ha escrit:
>> 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 gra
ularity, will be supported for years. Dropping any splitting in
a short future (3-5 years) will just break those guests to boot on Xen.
AFAIK, we never took a such radical decision on Xen based on the
complexity of the code.
Regards,
--
Julien Grall
--
To unsubscribe from this list: send
iff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> index f5ef674..4ebfcec 100644
> --- a/arch/x86/xen/setup.c
> +++ b/arch/x86/xen/setup.c
> @@ -548,7 +548,7 @@ static unsigned long __init xen_get_max_pages(void)
> {
> unsigned long max_pages, limit;
>
request. You may want
to give a look to this patch before looking to this series.
Regards,
[1] https://lwn.net/Articles/656797/
[2] http://www.spinics.net/lists/arm-kernel/msg430468.html
--
Julien Grall
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
se) will send an RFC to extend the grant size.
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/
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/
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
ations, so the change
is only arm32 specific.
Reported-by: Riku Voipio <riku.voi...@linaro.org>
Signed-off-by: Julien Grall <julien.gr...@citrix.com>
---
Cc: Stefano Stabellini <stefano.stabell...@eu.citrix.com>
Cc: Russell King <li...@arm.linux.org.uk>
Changes in v2:
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 <julien.gr...@citrix.com>
---
Cc: Konrad Rzeszutek Wilk <konrad.w...@oracle.com>
Cc
Rzeszutek Wilk <konrad.w...@oracle.com>
Cc: "Roger Pau Monné" <roger@citrix.com>
Cc: Boris Ostrovsky <boris.ostrov...@oracle.com>
Cc: David Vrabel <david.vra...@citrix.com>
Julien Grall (2):
block/xen-blkfront: Introduce blkif_ring_get_request
block/xen-b
The code to get a request is always the same. Therefore we can factorize
it in a single function.
Signed-off-by: Julien Grall <julien.gr...@citrix.com>
---
Cc: Konrad Rzeszutek Wilk <konrad.w...@oracle.com>
Cc: "Roger Pau Monné" <roger@citrix.com>
Cc: B
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
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/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
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
ations, so the change
is only arm32 specific.
Reported-by: Riku Voipio <riku.voi...@linaro.org>
Signed-off-by: Julien Grall <julien.gr...@citrix.com>
---
Cc: Stefano Stabellini <stefano.stabell...@eu.citrix.com>
Cc: Russell King <li...@arm.linux.org.uk>
ARM64 doesn't
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
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
Hi David,
On 29/09/15 17:27, David Vrabel wrote:
> On 07/09/15 16:33, Julien Grall wrote:
>>
>> A branch based on the latest xentip/for-linus-4.3 can be found here:
>>
>> git://xenbits.xen.org/people/julieng/linux-arm.git branch xen-64k-v4
>
> This has
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 <julien.gr...@citrix.com>
execution path, separate
the function in 2. This will also remove one level of tabulation.
Signed-off-by: Julien Grall <julien.gr...@citrix.com>
Reviewed-by: Roger Pau Monné <roger@citrix.com>
---
Cc: Konrad Rzeszutek Wilk <konrad.w...@oracle.com>
Cc: Boris Ostrovsky <boris
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 <julien.gr...@citrix.com>
Reviewed-by: Stefano Stabellini <stefano.stabell...@eu.citrix.com>
---
Cc: Konrad Rz
which result
to page_mfn not being defined when necessary.
Signed-off-by: Julien Grall <julien.gr...@linaro.org>
Reviewed-by: David Vrabel <david.vra...@citrix.com>
Reviewed-by: Stefano Stabellini <stefano.stabell...@eu.citrix.com>
---
Cc: Konrad Rzeszutek Wilk <konrad.w...@
On 30/09/15 11:45, Julien Grall wrote:
> Many PV drivers contain the idiom:
>
> pfn = page_to_gfn(...) /* Or similar */
> gnttab_grant_foreign_access_ref
>
> Replace it by a new helper. Note that when Linux is using a different
> page granularity than Xen, the hel
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 <julien.gr...@citrix.com>
Acked-by: Roger Pau Monné <roger...
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 <julien.gr...@citrix.com>
Reviewed-by: David Vrabel <david.vra...@citrix.com>
---
Cc: Konrad Rzeszutek Wilk <konrad.w...
on the grant table code.
Signed-off-by: Julien Grall <julien.gr...@citrix.com>
Reviewed-by: Wei Liu <wei.l...@citrix.com>
---
Cc: Ian Campbell <ian.campb...@citrix.com>
Cc: net...@vger.kernel.org
Improvement such as support of 64KB grant is not taken into
consideration in this pat
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 <julien.gr...@citrix.com>
Reviewed-by: David Vrabel <david.vra...@c
All the ring (xenstore, and PV rings) are always based on the page
granularity of Xen.
Signed-off-by: Julien Grall <julien.gr...@citrix.com>
Reviewed-by: David Vrabel <david.vra...@citrix.com>
Reviewed-by: Stefano Stabellini <stefano.stabell...@eu.citrix.com>
---
Cc: Kon
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 <julien.gr...@citrix.
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 <julien.gr...@citrix.com>
Reviewed-by: Stefano Stabellini <stefano.stabell...@eu.citrix.com>
---
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 <julien.gr...@citrix.com>
Reviewed-by: David Vrabel <david.vra...@citrix.com>
---
Cc: Konr
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
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 <julien.gr...@citrix.com>
Reviewed-by: Stefano Stabellini <stefan
chunk). That would require more care when we fail to expand the
event channel.
Signed-off-by: Julien Grall <julien.gr...@citrix.com>
Reviewed-by: David Vrabel <david.vra...@citrix.com>
Reviewed-by: Stefano Stabellini <stefano.stabell...@citrix.com>
---
Cc: Konrad Rzeszu
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 <julien
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 <julien
The console ring is always based on the page granularity of Xen.
Signed-off-by: Julien Grall <julien.gr...@citrix.com>
Reviewed-by: Stefano Stabellini <stefano.stabell...@eu.citrix.com>
---
Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
Cc: Jiri Slaby <jsl...@suse
On 30/09/15 12:32, Mark Rutland wrote:
> On Wed, Sep 30, 2015 at 11:45:15AM +0100, Julien Grall wrote:
>> Hi all,
>
> Hi,
>
>> ARM64 Linux is supporting both 4KB and 64KB page granularity. Although, Xen
>> hypercall interface and PV protocol are always based on 4
in this series
m: Minor changes in this series due to conflict during rebase
L: Missing Acked-by from a Linux maintainers (Boris, David or Konrad)
Julien Grall (22):
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 L xen: Add
the compilation. Furthermore, only definition in
interface/grant_table.h is required.
Signed-off-by: Julien Grall <julien.gr...@citrix.com>
Reviewed-by: David Vrabel <david.vra...@citrix.com>
Reviewed-by: Stefano Stabellini <stefano.stabell...@eu.citrix.com>
---
Cc: Konrad Rzeszu
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 <julien.gr...@citrix.com>
Reviewed-by: Stefano Stab
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 <julien.gr...@citrix.com>
Acked-by: Wei Liu <wei.l...@citrix.com>
---
Cc: Ian Campbell <ian.campb...@citrix.com>
Cc: net.
-off-by: Julien Grall <julien.gr...@citrix.com>
Reviewed-by: Stefano Stabellini <stefano.stabell...@eu.citrix.com>
---
Cc: Konrad Rzeszutek Wilk <konrad.w...@oracle.com>
Cc: Boris Ostrovsky <boris.ostrov...@oracle.com>
Cc: David Vrabel <david.vra...@citrix.com>
On 28/09/15 15:02, Boris Ostrovsky wrote:
> On 09/28/2015 09:59 AM, Julien Grall wrote:
>> Hi David,
>>
>> On 28/09/15 14:52, David Vrabel wrote:
>>> On 28/09/15 14:30, Julien Grall wrote:
>>>> The PCI support for Xen doesn't compile on ARM/ARM64 when
>
Hi David,
On 28/09/15 14:52, David Vrabel wrote:
> On 28/09/15 14:30, Julien Grall wrote:
>> The PCI support for Xen doesn't compile on ARM/ARM64 when
>> CONFIG_PCI_MMCONFIG=y:
>>
>> drivers/xen/pci.c:31:25: fatal error: asm/pci_x86.h: No such file or
>> direc
On 28/09/15 14:48, Stefano Stabellini wrote:
> On Mon, 28 Sep 2015, Julien Grall wrote:
>> The PCI support for Xen doesn't compile on ARM/ARM64 when
>> CONFIG_PCI_MMCONFIG=y:
>>
>> drivers/xen/pci.c:31:25: fatal error: asm/pci_x86.h: No such file or
>> directory
Hi David,
On 02/10/15 15:09, David Vrabel wrote:
> On 30/09/15 11:45, 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
Hi,
Ping, any comment on this series?
Regards,
On 11/09/15 20:31, Julien Grall wrote:
> Hi all,
>
> This is a follow-up on the previous discussion [1] related to guest using 64KB
> page granularity not booting with backend using non-indirect grant.
>
> This has been success
On 02/10/15 15:31, Julien Grall wrote:
> Hi David,
>
> On 02/10/15 15:09, David Vrabel wrote:
>> On 30/09/15 11:45, Julien Grall wrote:
>>> For ARM64 guests, Linux is able to support either 64K or 4K page
>>> granularity. Although, the hypercall interfa
some changes in Linux
side.
For now, introduce a new config options XEN_PCI which will be turned off
for ARM platform.
Reported-by: Robert Richter <robert.rich...@caviumnetworks.com>
Signed-off-by: Julien Grall <julien.gr...@citrix.com>
---
Cc: Konrad Rzeszutek Wilk <konrad.w...
t GIC
>* as 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/
.
A branch has been pushed based on the lastest staging:
git://xenbits.xen.org/people/julieng/xen-unstable.git branch gicv3-32bit-v1
Sincerely yours,
Julien Grall (8):
xen/arm: io: remove mmio_check_t typedef
xen/arm: io: Extend write/read handler to pass the register in
parameter
xen/arm
supports any access size and expect the caller to
validate the access size supported by the emulated registers.
Finally, take the opportunity to fix the coding style in section we are
modifying.
Signed-off-by: Julien Grall <julien.gr...@citrix.com>
---
I've only done quick tests. I sen
Signed-off-by: Julien Grall <julien.gr...@citrix.com>
---
Changes in v2:
- Patch added
---
xen/include/asm-arm/domain.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index c3f5a95..1a5bfd7
From: Julien Grall <julien.gr...@linaro.org>
Rather than letting each handler to retrieve the register used by the
I/O access, add a new parameter to pass the register in parameter.
This will help to implement generic register manipulation on I/O access
such as sign-extension and end
. This is fine because the GIC spec doesn't
require to return exactly the value written and it can be seen as if we
decide to implement the register read-only.
Finally take the opportunity to fix coding style in section we are
modifying.
Signed-off-by: Julien Grall <julien.gr...@citrix.
From: Julien Grall <julien.gr...@linaro.org>
This typedef is a left-over of the previous MMIO emulation
implementation.
Signed-off-by: Julien Grall <julien.gr...@linaro.org>
---
Changes in v2:
- Patch added
---
xen/include/asm-arm/mmio.h | 1 -
1 file changed, 1 delet
in vGIG
emulation. Although there is no reason to not have it generically.
So move the support just after we get the data from the MMIO emulation.
Signed-off-by: Julien Grall <julien.gr...@citrix.com>
---
I was thinking to completely drop the sign-extension support in Xen as
it will b
Please ignore this version, I've sent it to the wrong mailing list.
Sorry for the noise.
On 25/09/15 15:50, Julien Grall wrote:
> Hi all,
>
> This series aims to fix the 32-bit access on 64-bit register. Some guest
> OS such as FreeBSD and Linux (only in the ITS) use 3
for them doesn't hurt. Note that we would need
some extra care when they will be implemented (for instance GICR_PROPBASER).
Signed-off-by: Julien Grall <julien.gr...@citrix.com>
---
This is technically fixing boot of FreeBSD ARM64 guest with GICv3.
AFAICT, Linux is not using 32-bit
. The emulation code will now have to generate the GICD_PRIORITYR
register for read access and split it to store in a convenient way.
Signed-off-by: Julien Grall <julien.gr...@citrix.com>
---
The real reason is I'd like to drop vgic_byte_* helpers in favors of more
generic access helper. Although it woul
Hi Konrad,
On 09/09/2015 16:02, Konrad Rzeszutek Wilk wrote:
Konrad, would you like me to resend the patch with the modified commit
message, or do you plan to amend it yourself while committing?
I will amend it. Thanks!
What the status for this patch?
Regards,
--
Julien Grall
overhead with my series is about 0.56%.
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/
On 05/10/15 17:01, Roger Pau Monné wrote:
> El 11/09/15 a les 21.32, Julien Grall ha escrit:
>> The minimal size of request in the block framework is always PAGE_SIZE.
>> It means that when 64KB guest is support, the request will at least be
>> 64KB.
>>
>> Althoug
Hi Konrad,
On 01/12/15 18:52, Konrad Rzeszutek Wilk wrote:
> On Tue, Dec 01, 2015 at 05:55:48PM +0000, Julien Grall wrote:
>> Hi Konrad,
>>
>> On 01/12/15 15:37, Konrad Rzeszutek Wilk wrote:
>>> On Wed, Nov 18, 2015 at 06:57:23PM +, Julien Grall wrote:
>>&
bility of the code. It even
make it worth in the two cases.
--
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
301 - 400 of 1315 matches
Mail list logo
