On Wed, 24 Mar 2021, Randy Dunlap wrote:
> On 3/24/21 9:35 PM, Bhaskar Chowdhury wrote:
> > s/acrros/across/
> >
> > Plus some words need prural version...so did it.(page->pages)
> >
> > Signed-off-by: Bhaskar Chowdhury
>
> Acked-by: R
On Wed, 24 Mar 2021, Randy Dunlap wrote:
> On 3/24/21 11:55 AM, Stefano Stabellini wrote:
> > On Wed, 24 Mar 2021, Bhaskar Chowdhury wrote:
> >> s/acrros/across/
> >>
> >> Signed-off-by: Bhaskar Chowdhury
> >
> > Reviewed-by: Stefano Stabellini
On Wed, 24 Mar 2021, Bhaskar Chowdhury wrote:
> s/acrros/across/
>
> Signed-off-by: Bhaskar Chowdhury
Reviewed-by: Stefano Stabellini
> ---
> arch/arm/xen/mm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/xen/mm.c b/a
On Fri, 19 Mar 2021, Konrad Rzeszutek Wilk wrote:
> On Fri, Mar 19, 2021 at 02:07:31PM +0100, Christoph Hellwig wrote:
> > On Thu, Mar 18, 2021 at 09:03:33PM -0700, Florian Fainelli wrote:
> > > #ifdef CONFIG_ARM_LPAE
> > > + if (swiotlb_force == SWIOTLB_FORCE ||
> > > + max_pfn > arm_dma_pfn_
On Fri, 19 Feb 2021, Konrad Rzeszutek Wilk wrote:
> On Sun, Feb 07, 2021 at 04:56:01PM +0100, Christoph Hellwig wrote:
> > On Thu, Feb 04, 2021 at 09:40:23AM +0100, Christoph Hellwig wrote:
> > > So one thing that has been on my mind for a while: I'd really like
> > > to kill the separate dma ops
t; > Fixes: 3499ba8198cad ("xen: Fix event channel callback via INTX/GSI")
> > Reported-by: Ian Jackson
> > Signed-off-by: Julien Grall
>
> Reviewed-by: David Woodhouse
> Cc: sta...@vger.kernel.org
Reviewed-by: Stefano Stabellini
next later this week.
Looks fine, thank you
> >From a1eb2768bf5954d25aa0f0136b38f0aa5d92d984 Mon Sep 17 00:00:00 2001
> From: Stefano Stabellini
> Date: Mon, 26 Oct 2020 17:02:14 -0700
> Subject: [PATCH] swiotlb: fix "x86: Don't panic if can not alloc buffer for
> swio
On Tue, 27 Oct 2020, Konrad Rzeszutek Wilk wrote:
> On Mon, Oct 26, 2020 at 05:02:14PM -0700, Stefano Stabellini wrote:
> > From: Stefano Stabellini
> >
> > kernel/dma/swiotlb.c:swiotlb_init gets called first and tries to
> > allocate a buffer for the swi
From: Stefano Stabellini
kernel/dma/swiotlb.c:swiotlb_init gets called first and tries to
allocate a buffer for the swiotlb. It does so by calling
memblock_alloc_low(PAGE_ALIGN(bytes), PAGE_SIZE);
If the allocation must fail, no_iotlb_memory is set.
Later during initialization swiotlb-xen
On Mon, 5 Oct 2020, Ben Levinsky wrote:
> R5 is included in Xilinx Zynq UltraScale MPSoC so by adding this
> remotproc driver, we can boot the R5 sub-system in different 2
> configurations -
> * split
> * lock-step
>
> The Xilinx R5 Remoteproc Driver boots the R5's via calls to the Xil
On Thu, 8 Oct 2020, Ben Levinsky wrote:
> > Does it mean that the main CPU see the memory of the
> > R5 as "some kind of TCM" and that TCM is physically
> > mapped at 0xffe0 (ITCM) and 0xffe2 (DTCM)?
> >
> > If the first is ITCM and the second DTCM that is pretty
> > important to point out
On Thu, 8 Oct 2020, Masami Hiramatsu wrote:
> On Tue, 6 Oct 2020 10:56:52 -0700 (PDT)
> Stefano Stabellini wrote:
>
> > On Tue, 6 Oct 2020, Masami Hiramatsu wrote:
> > > On Mon, 5 Oct 2020 18:13:22 -0700 (PDT)
> > > Stefano Stabellini wrote:
> > >
>
95b5309a33f8b28 ]---
> [0.832076] Kernel panic - not syncing: Attempted to kill init!
> exitcode=0x000b
> [0.839815] ---[ end Kernel panic - not syncing: Attempted to kill init!
> exitcode=0x000b ]---
>
> Theoletically, this issue has been introduced by commit 9
On Tue, 6 Oct 2020, Masami Hiramatsu wrote:
> On Mon, 5 Oct 2020 18:13:22 -0700 (PDT)
> Stefano Stabellini wrote:
>
> > On Mon, 5 Oct 2020, Julien Grall wrote:
> > > Hi Masami,
> > >
> > > On 05/10/2020 14:39, Masami Hiramatsu wrote:
> > >
> /* Only used in PV code. But ARM guests are always HVM. */
> > static inline xmaddr_t arbitrary_virt_to_machine(void *vaddr)
> > {
The fix is fine for me. I tested it and it works. We need to remove the
"Fixes:" line from the commit message. Ideally, replacing it with a
reference to what is the source of the problem.
Aside from that:
Reviewed-by: Stefano Stabellini
On Tue, 29 Sep 2020, Rob Herring wrote:
> > index ..ce02e425692e
> > --- /dev/null
> > +++
> > b/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml
> > @@ -0,0 +1,120 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$i
From: Stefano Stabellini
The VCPUOP_register_runstate_memory_area hypercall takes a virtual
address of a buffer as a parameter. The semantics of the hypercall are
such that the virtual address should always be valid.
When KPTI is enabled and we are running userspace code, the virtual
address is
On Fri, 4 Sep 2020, Ben Levinsky wrote:
> Add binding for ZynqMP R5 OpenAMP.
>
> Represent the RPU domain resources in one device node. Each RPU
> processor is a subnode of the top RPU domain node.
>
> Signed-off-by: Jason Wu
> Signed-off-by: Wendy Liang
> Signed-off-by: Michal Simek
>
> Sign
On Mon, 24 Aug 2020, Ben Levinsky wrote:
> > -Original Message-
> > From: linux-remoteproc-ow...@vger.kernel.org > ow...@vger.kernel.org> On Behalf Of Ben Levinsky
> > Sent: Tuesday, August 18, 2020 7:24 AM
> > To: Stefano Stabellini
> > Cc: Micha
On Tue, 18 Aug 2020, Ben Levinsky wrote:
> > > +/**
> > > + * struct zynqmp_r5_mem - zynqmp rpu memory data
> > > + * @pnode_id: TCM power domain ids
> > > + * @res: memory resource
> > > + * @node: list node
> > > + */
> > > +struct zynqmp_r5_mem {
> > > + u32 pnode_id[MAX_MEM_PNODES];
> > > + str
On Mon, 10 Aug 2020, Ben Levinsky wrote:
> R5 is included in Xilinx Zynq UltraScale MPSoC so by adding this
> remotproc driver, we can boot the R5 sub-system in different
> configurations.
Which different configurations? How can you boot them?
> Signed-off-by: Ben Levinsky
> Signed-off-by: Wend
On Mon, 10 Aug 2020, Ben Levinsky wrote:
> Add shutdown/wakeup a resource eemi operations to shutdown
> or bringup a resource.
>
> Signed-off-by: Ben Levinsky
> ---
> v3:
> - add xilinx-related platform mgmt fn's instead of wrapping around
> function pointer in xilinx eemi ops struct
> - fix fo
On Mon, 10 Aug 2020, Ben Levinsky wrote:
> This patch adds APIs to provide access and a configuration interface
> to the current power state of a sub-system on Zynqmp sub-system.
This doesn't read correctly
> Signed-off-by: Ben Levinsky
> ---
> v3:
> - add xilinx-related platform mgmt fn's inst
On Tue, 4 Aug 2020, Jürgen Groß wrote:
> On 11.07.20 00:34, Stefano Stabellini wrote:
> > Hi all,
> >
> > This series is a collection of fixes to get Linux running on the RPi4 as
> > dom0. Conceptually there are only two significant changes:
> >
> >
On Tue, 28 Jul 2020, Mathieu Poirier wrote:
> On Wed, Jul 15, 2020 at 08:33:17AM -0700, Ben Levinsky wrote:
> > R5 is included in Xilinx Zynq UltraScale MPSoC so by adding this
> > remotproc driver, we can boot the R5 sub-system in different
> > configurations.
>
On Thu, 23 Jul 2020, Anchal Agarwal wrote:
> On Wed, Jul 22, 2020 at 04:49:16PM -0700, Stefano Stabellini wrote:
> > CAUTION: This email originated from outside of the organization. Do not
> > click links or open attachments unless you can confirm the sender and know
> >
On Wed, 22 Jul 2020, Anchal Agarwal wrote:
> On Tue, Jul 21, 2020 at 05:18:34PM -0700, Stefano Stabellini wrote:
> > On Tue, 21 Jul 2020, Boris Ostrovsky wrote:
> > > >>>>>> +static int xen_setup_pm_notifier(void)
> > > >
On Tue, 21 Jul 2020, Boris Ostrovsky wrote:
> >> +static int xen_setup_pm_notifier(void)
> >> +{
> >> + if (!xen_hvm_domain())
> >> + return -ENODEV;
> >>
> >> I forgot --- what did we decide about non-x86 (i.e. ARM)?
> > It would be great to support that
On Thu, 16 Jul 2020, Mathieu Poirier wrote:
> Hi Rob,
>
> On Tue, Jul 14, 2020 at 11:15:53AM -0600, Rob Herring wrote:
> > On Mon, Jun 29, 2020 at 09:49:19PM -0500, Suman Anna wrote:
> > > The Texas Instruments K3 family of SoCs have one or more dual-core
> > > Arm Cortex R5F processor subsystems/
On Sat, 11 Jul 2020, Michael S. Tsirkin wrote:
> On Fri, Jul 10, 2020 at 10:23:22AM -0700, Stefano Stabellini wrote:
> > Sorry for the late reply -- a couple of conferences kept me busy.
> >
> >
> > On Wed, 1 Jul 2020, Michael S. Tsirkin wrote:
> > > On W
From: Stefano Stabellini
No functional changes. The parameter is unused in this patch but will be
used by next patches.
Signed-off-by: Stefano Stabellini
Reviewed-by: Boris Ostrovsky
Tested-by: Corey Minyard
Tested-by: Roman Shaposhnik
---
Changes in v3:
- add whitespace in title
- improve
on vmalloc
virt addresses.
This patch fixes the following crash at boot on RPi4 (the underlying
issue is not RPi4 specific):
https://marc.info/?l=xen-devel&m=158862573216800
Signed-off-by: Boris Ostrovsky
Signed-off-by: Stefano Stabellini
Reviewed-by: Boris Ostrovsky
Tested-by: Corey Minyar
From: Stefano Stabellini
dma_cache_maint is getting called passing a dma address which could be
different from a physical address.
Add a struct device* parameter to dma_cache_maint.
Translate the dma_addr_t parameter of dma_cache_maint by calling
dma_to_phys. Do it for the first page and all
From: Stefano Stabellini
xen_dma_sync_for_cpu, xen_dma_sync_for_device, xen_arch_need_swiotlb are
getting called passing dma addresses. On some platforms dma addresses
could be different from physical addresses. Before doing any operations
on these addresses we need to convert them back to
From: Stefano Stabellini
With some devices physical addresses are different than dma addresses.
To be able to deal with these cases, we need to call phys_to_dma on
physical addresses (including machine addresses in Xen terminology)
before returning them from xen_swiotlb_alloc_coherent and
From: Stefano Stabellini
XEN_PFN_PHYS is only used in one place in swiotlb-xen making things more
complex than need to be.
Remove the definition of XEN_PFN_PHYS and open code the cast in the one
place where it is needed.
Signed-off-by: Stefano Stabellini
---
drivers/xen/swiotlb-xen.c | 7
From: Stefano Stabellini
No functional changes. The parameter is unused in this patch but will be
used by next patches.
Signed-off-by: Stefano Stabellini
Reviewed-by: Boris Ostrovsky
Tested-by: Corey Minyard
Tested-by: Roman Shaposhnik
---
Changes in v3:
- add whitespace in title
- improve
From: Stefano Stabellini
No functional changes. The parameter is unused in this patch but will be
used by next patches.
Signed-off-by: Stefano Stabellini
Reviewed-by: Boris Ostrovsky
Tested-by: Corey Minyard
Tested-by: Roman Shaposhnik
---
Changes in v3:
- add whitespace in title
- improve
From: Stefano Stabellini
It is not strictly needed. Call virt_to_phys on xen_io_tlb_start
instead. It will be useful not to have a start_dma_addr around with the
next patches.
Note that virt_to_phys is not the same as xen_virt_to_bus but actually
it is used to compared again __pa
From: Stefano Stabellini
No functional changes. The parameter is unused in this patch but will be
used by next patches.
Signed-off-by: Stefano Stabellini
Reviewed-by: Boris Ostrovsky
Tested-by: Corey Minyard
Tested-by: Roman Shaposhnik
---
Changes in v3:
- add whitespace in title
- improve
From: Stefano Stabellini
No functional changes. The parameter is unused in this patch but will be
used by next patches.
Signed-off-by: Stefano Stabellini
Reviewed-by: Boris Ostrovsky
Tested-by: Corey Minyard
Tested-by: Roman Shaposhnik
---
Changes in v3:
- add whitespace in title
- improve
git fix-rpi4-v3
Boris Ostrovsky (1):
swiotlb-xen: use vmalloc_to_page on vmalloc virt addresses
Stefano Stabellini (10):
swiotlb-xen: remove start_dma_addr
swiotlb-xen: add struct device * parameter to xen_phys_to_bus
swiotlb-xen: add struct device * parameter to
Sorry for the late reply, a couple of conferences kept me busy.
On Mon, 29 Jun 2020, Bjorn Andersson wrote:
> > However, given the fragmentation of the remoteproc bindings across
> > multiple vendors (they are all different), I think it is a good idea for
> > Linux, for System Device Tree, and in
Sorry for the late reply -- a couple of conferences kept me busy.
On Wed, 1 Jul 2020, Michael S. Tsirkin wrote:
> On Wed, Jul 01, 2020 at 10:34:53AM -0700, Stefano Stabellini wrote:
> > Would you be in favor of a more flexible check along the lines of the
> > one proposed in
On Wed, 1 Jul 2020, Christoph Hellwig wrote:
> On Mon, Jun 29, 2020 at 04:46:09PM -0700, Stefano Stabellini wrote:
> > > I could imagine some future Xen hosts setting a flag somewhere in the
> > > platform capability saying "no xen specific flag, rely on
> > > &
On Wed, 10 Jun 2020, Rob Herring wrote:
> On Tue, May 26, 2020 at 11:40 AM Ben Levinsky wrote:
> >
> > Hi Rob,
> >
> > The Xilinx R5 Remoteproc driver has been around for a long time --
> > admittedly we should have upstreamed it long ago. The driver in the current
> > form is using an "classic"
On Mon, 29 Jun 2020, Peng Fan wrote:
> > > If that is the case, how is it possible that virtio breaks on ARM
> > > using the default dma_ops? The breakage is not Xen related (except
> > > that Xen turns dma_ops on). The original message from Peng was:
> > >
> > > vring_map_one_sg -> vring_use_dma
On Fri, 26 Jun 2020, Michael S. Tsirkin wrote:
> On Thu, Jun 25, 2020 at 10:31:27AM -0700, Stefano Stabellini wrote:
> > On Wed, 24 Jun 2020, Michael S. Tsirkin wrote:
> > > On Wed, Jun 24, 2020 at 02:53:54PM -0700, Stefano Stabellini wrote:
> > > > On Wed, 24 Jun
On Tue, 30 Jun 2020, Stephen Rothwell wrote:
> Hi all,
>
> Commit
>
> 724f239c3401 ("arm/xen: remove the unused macro GRANT_TABLE_PHYSADDR")
>
> is missing a Signed-off-by from its committer.
Fixed. Thank you so much, I love linux-next :-)
t; was deleted in the following commit 3cf4095d7446 ("arm/xen: Use
> xen_xlate_map_ballooned_pages to setup grant table")
>
> Signed-off-by: Xiaofei Tan
Reviewed-by: Stefano Stabellini
> ---
> arch/arm/xen/enlighten.c | 1 -
> 1 file changed, 1 deletion(-
On Wed, 24 Jun 2020, Michael S. Tsirkin wrote:
> On Wed, Jun 24, 2020 at 02:53:54PM -0700, Stefano Stabellini wrote:
> > On Wed, 24 Jun 2020, Michael S. Tsirkin wrote:
> > > On Wed, Jun 24, 2020 at 10:59:47AM -0700, Stefano Stabellini wrote:
> > > > On Wed, 24 Jun
On Wed, 24 Jun 2020, Michael S. Tsirkin wrote:
> On Wed, Jun 24, 2020 at 10:59:47AM -0700, Stefano Stabellini wrote:
> > On Wed, 24 Jun 2020, Michael S. Tsirkin wrote:
> > > On Wed, Jun 24, 2020 at 05:17:32PM +0800, Peng Fan wrote:
> > > > Export xen_swiotlb for a
On Wed, 24 Jun 2020, Michael S. Tsirkin wrote:
> On Wed, Jun 24, 2020 at 05:17:32PM +0800, Peng Fan wrote:
> > Export xen_swiotlb for all platforms using xen swiotlb
> >
> > Use xen_swiotlb to determine when vring should use dma APIs to map the
> > ring: when xen_swiotlb is enabled the dma API is
On Mon, 8 Jun 2020, Christoph Hellwig wrote:
> On Mon, Jun 08, 2020 at 10:38:02PM -0700, Christoph Hellwig wrote:
> > On Mon, Jun 08, 2020 at 05:38:28PM -0700, Stefano Stabellini wrote:
> > > Yeah, the pfn_valid check is a bit weird by definition because we are
> > > usi
On Mon, 8 Jun 2020, Christoph Hellwig wrote:
> On Mon, Jun 08, 2020 at 04:06:57PM -0700, Stefano Stabellini wrote:
> > I understand what you are suggesting about having something like:
> >
> > xen_phys_to_dma(...)
> > {
> > phys_addr_t
On Mon, 8 Jun 2020, Stefano Stabellini wrote:
> On Mon, 8 Jun 2020, Christoph Hellwig wrote:
> > On Wed, Jun 03, 2020 at 03:22:44PM -0700, Stefano Stabellini wrote:
> > > From: Stefano Stabellini
> > >
> > > With some devices physical addresses are different
On Mon, 8 Jun 2020, Christoph Hellwig wrote:
> On Wed, Jun 03, 2020 at 03:22:46PM -0700, Stefano Stabellini wrote:
> > From: Stefano Stabellini
> >
> > xen_dma_sync_for_cpu, xen_dma_sync_for_device, xen_arch_need_swiotlb are
> > getting called passing dma addre
On Mon, 8 Jun 2020, Christoph Hellwig wrote:
> On Wed, Jun 03, 2020 at 03:22:44PM -0700, Stefano Stabellini wrote:
> > From: Stefano Stabellini
> >
> > With some devices physical addresses are different than dma addresses.
> > To be able to deal with these cases, we
On Mon, 8 Jun 2020, Christoph Hellwig wrote:
> On Wed, Jun 03, 2020 at 03:22:39PM -0700, Stefano Stabellini wrote:
> > From: Stefano Stabellini
> >
> > The parameter is unused in this patch.
> > No functional changes.
>
> This looks weird. I'm pretty s
Hi Christoph,
Thanks you for the review.
On Mon, 8 Jun 2020, Christoph Hellwig wrote:
> Well, this isn't just RPi4, but basically any ARM or ARM64 system
> with non-coherent DMA (which is most of them).
Well... yes :-)
> > + struct page *pg;
>
> Please spell out page.
OK
> >
> > i
From: Stefano Stabellini
It is not strictly needed. Call virt_to_phys on xen_io_tlb_start
instead. It will be useful not to have a start_dma_addr around with the
next patches.
Note that virt_to_phys is not the same as xen_virt_to_bus but actually
it is used to compared again __pa
5:53 -0700)
Boris Ostrovsky (1):
swiotlb-xen: use vmalloc_to_page on vmalloc virt addresses
Stefano Stabellini (10):
swiotlb-xen: remove start_dma_addr
swiotlb-xen: add struct device* parameter to xen_phys_to_bus
swiotlb-xen: add struct device* pa
From: Stefano Stabellini
dma_cache_maint is getting called passing a dma address which could be
different from a physical address.
Add a struct device* parameter to dma_cache_maint.
Translate the dma_addr_t parameter of dma_cache_maint by calling
dma_to_phys. Do it for the first page and all
From: Stefano Stabellini
The parameter is unused in this patch.
No functional changes.
Signed-off-by: Stefano Stabellini
Tested-by: Corey Minyard
Tested-by: Roman Shaposhnik
---
arch/arm/xen/mm.c | 5 +++--
drivers/xen/swiotlb-xen.c | 4 ++--
include/xen/swiotlb-xen.h | 5 +++--
3
From: Stefano Stabellini
The parameter is unused in this patch.
No functional changes.
Signed-off-by: Stefano Stabellini
Tested-by: Corey Minyard
Tested-by: Roman Shaposhnik
---
drivers/xen/swiotlb-xen.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/xen
on vmalloc
virt addresses.
This patch fixes the following crash at boot on RPi4:
https://marc.info/?l=xen-devel&m=158862573216800
Signed-off-by: Boris Ostrovsky
Signed-off-by: Stefano Stabellini
Tested-by: Corey Minyard
Tested-by: Roman Shaposhnik
---
Changes in v2:
- update commit message
---
From: Stefano Stabellini
The parameter is unused in this patch.
No functional changes.
Signed-off-by: Stefano Stabellini
Tested-by: Corey Minyard
Tested-by: Roman Shaposhnik
---
drivers/xen/swiotlb-xen.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a
so that their names can better describe their behavior.
No functional changes.
Signed-off-by: Stefano Stabellini
---
drivers/xen/swiotlb-xen.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index
From: Stefano Stabellini
The parameter is unused in this patch.
No functional changes.
Signed-off-by: Stefano Stabellini
Tested-by: Corey Minyard
Tested-by: Roman Shaposhnik
---
arch/arm/xen/mm.c | 5 +++--
drivers/xen/swiotlb-xen.c | 4 ++--
include/xen/swiotlb-xen.h | 5 +++--
3
From: Stefano Stabellini
The parameter is unused in this patch.
No functional changes.
Signed-off-by: Stefano Stabellini
Tested-by: Corey Minyard
Tested-by: Roman Shaposhnik
---
drivers/xen/swiotlb-xen.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers
From: Stefano Stabellini
xen_dma_sync_for_cpu, xen_dma_sync_for_device, xen_arch_need_swiotlb are
getting called passing dma addresses. On some platforms dma addresses
could be different from physical addresses. Before doing any operations
on these addresses we need to convert them back to
From: Stefano Stabellini
With some devices physical addresses are different than dma addresses.
To be able to deal with these cases, we need to call phys_to_dma on
physical addresses (including machine addresses in Xen terminology)
before returning them from xen_swiotlb_alloc_coherent and
I would like to ask the maintainers, Juergen, Boris, Konrad, whether you
have any more feedback before I send v2 of the series.
Cheers,
Stefano
On Wed, 20 May 2020, Stefano Stabellini wrote:
> Hi all,
>
> This series is a collection of fixes to get Linux running on the RPi4
On Tue, 2 Jun 2020, Dominique Martinet wrote:
> Stefano Stabellini wrote on Mon, Jun 01, 2020:
> > > LGTM, I'll try to find some time to test this by the end of next week or
> > > will trust you if I can't make it -- ping me around June 1st if I don't
> >
n Fri, 22 May 2020, Dominique Martinet wrote:
> Stefano Stabellini wrote on Thu, May 21, 2020:
> > From: Stefano Stabellini
> >
> > Increase XEN_9PFS_RING_ORDER to 9 for performance reason. Order 9 is the
> > max allowed by the protocol.
> >
> > We can&
On Fri, 22 May 2020, Julien Grall wrote:
> On 22/05/2020 04:55, Stefano Stabellini wrote:
> > On Thu, 21 May 2020, Julien Grall wrote:
> > > Hi,
> > >
> > > On 21/05/2020 00:45, Stefano Stabellini wrote:
> > > > From: Stefano Stabellini
On Fri, 22 May 2020, Julien Grall wrote:
> Hi Stefano,
>
> On 22/05/2020 04:54, Stefano Stabellini wrote:
> > On Thu, 21 May 2020, Julien Grall wrote:
> > > Hi,
> > >
> > > On 21/05/2020 00:45, Stefano Stabellini wrote:
> > > > From: Bo
On Thu, 21 May 2020, Boris Ostrovsky wrote:
> On 5/20/20 7:45 PM, Stefano Stabellini wrote:
> > From: Stefano Stabellini
> >
> > Call dma_to_phys in is_xen_swiotlb_buffer.
> > Call phys_to_dma in xen_phys_to_bus.
> > Call dma_to_phys in xen_bus_to_phys.
>
On Thu, 21 May 2020, Julien Grall wrote:
> Hi,
>
> On 21/05/2020 00:45, Stefano Stabellini wrote:
> > From: Boris Ostrovsky
> >
> > Don't just assume that virt_to_page works on all virtual addresses.
> > Instead add a is_vmalloc_addr check and use vmalloc
On Thu, 21 May 2020, Julien Grall wrote:
> Hi,
>
> On 21/05/2020 00:45, Stefano Stabellini wrote:
> > From: Stefano Stabellini
> >
> > It is not strictly needed. Call virt_to_phys on xen_io_tlb_start
> > instead. It will be useful not to have a start_dma_addr
On Thu, 21 May 2020, Julien Grall wrote:
> > @@ -97,8 +98,7 @@ bool xen_arch_need_swiotlb(struct device *dev,
> >phys_addr_t phys,
> >dma_addr_t dev_addr)
> > {
> > - unsigned int xen_pfn = XEN_PFN_DOWN(phys);
> > - unsigned int bfn = XEN_PFN_DO
From: Stefano Stabellini
Increase XEN_9PFS_RING_ORDER to 9 for performance reason. Order 9 is the
max allowed by the protocol.
We can't assume that all backends will support order 9. The xenstore
property max-ring-page-order specifies the max order supported by the
backend. We'll us
On Wed, 20 May 2020, Roman Shaposhnik wrote:
> On Wed, May 20, 2020 at 4:45 PM Stefano Stabellini
> wrote:
> >
> > Hi all,
> >
> > This series is a collection of fixes to get Linux running on the RPi4 as
> > dom0.
> >
> > Conceptually there are o
From: Stefano Stabellini
The parameter is unused in this patch.
No functional changes.
Signed-off-by: Stefano Stabellini
---
drivers/xen/swiotlb-xen.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index
From: Stefano Stabellini
Add phys_to_dma/dma_to_phys calls to
xen_dma_sync_for_cpu, xen_dma_sync_for_device, and
xen_arch_need_swiotlb.
In xen_arch_need_swiotlb, take the opportunity to switch to the simpler
pfn_valid check we use everywhere else.
dma_cache_maint is fixed by the next patch
From: Stefano Stabellini
The parameter is unused in this patch.
No functional changes.
Signed-off-by: Stefano Stabellini
---
arch/arm/xen/mm.c | 5 +++--
drivers/xen/swiotlb-xen.c | 4 ++--
include/xen/swiotlb-xen.h | 5 +++--
3 files changed, 8 insertions(+), 6 deletions(-)
diff
From: Stefano Stabellini
It is not strictly needed. Call virt_to_phys on xen_io_tlb_start
instead. It will be useful not to have a start_dma_addr around with the
next patches.
Signed-off-by: Stefano Stabellini
---
drivers/xen/swiotlb-xen.c | 5 +
1 file changed, 1 insertion(+), 4
From: Stefano Stabellini
Add a struct device* parameter to dma_cache_maint.
Translate the dma_addr_t parameter of dma_cache_maint by calling
dma_to_phys. Do it for the first page and all the following pages, in
case of multipage handling.
Signed-off-by: Stefano Stabellini
---
arch/arm/xen
From: Stefano Stabellini
The parameter is unused in this patch.
No functional changes.
Signed-off-by: Stefano Stabellini
---
arch/arm/xen/mm.c | 5 +++--
drivers/xen/swiotlb-xen.c | 4 ++--
include/xen/swiotlb-xen.h | 5 +++--
3 files changed, 8 insertions(+), 6 deletions(-)
diff
From: Stefano Stabellini
Call dma_to_phys in is_xen_swiotlb_buffer.
Call phys_to_dma in xen_phys_to_bus.
Call dma_to_phys in xen_bus_to_phys.
Everything is taken care of by these changes except for
xen_swiotlb_alloc_coherent and xen_swiotlb_free_coherent, which need a
few explicit phys_to_dma
From: Stefano Stabellini
The parameter is unused in this patch.
No functional changes.
Signed-off-by: Stefano Stabellini
---
drivers/xen/swiotlb-xen.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index
From: Boris Ostrovsky
Don't just assume that virt_to_page works on all virtual addresses.
Instead add a is_vmalloc_addr check and use vmalloc_to_page on vmalloc
virt addresses.
Signed-off-by: Boris Ostrovsky
Signed-off-by: Stefano Stabellini
---
drivers/xen/swiotlb-xen.c | 5 -
1
From: Stefano Stabellini
The parameter is unused in this patch.
No functional changes.
Signed-off-by: Stefano Stabellini
---
drivers/xen/swiotlb-xen.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index
Hi all,
This series is a collection of fixes to get Linux running on the RPi4 as
dom0.
Conceptually there are only two significant changes:
- make sure not to call virt_to_page on vmalloc virt addresses (patch
#1)
- use phys_to_dma and dma_to_phys to translate phys to/from dma
addresses (all
On Wed, 20 May 2020, Dominique Martinet wrote:
> Stefano Stabellini wrote on Wed, May 20, 2020:
> > From: Stefano Stabellini
> >
> > Increase XEN_9PFS_RING_ORDER to 9 for performance reason. Order 9 is the
> > max allowed by the protocol.
> >
> > We can&
From: Stefano Stabellini
Increase XEN_9PFS_RING_ORDER to 9 for performance reason. Order 9 is the
max allowed by the protocol.
We can't assume that all backends will support order 9. The xenstore
property max-ring-page-order specifies the max order supported by the
backend. We'll us
On Mon, 11 May 2020, Juergen Gross wrote:
> backend_connect() can fail, so switch the device to connected only if
> no error occurred.
>
> Fixes: 0a9c75c2c7258f2 ("xen/pvcalls: xenbus state handling")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Juergen Gross
Rev
On Tue, 28 Apr 2020, Michael S. Tsirkin wrote:
> On Tue, Apr 28, 2020 at 11:19:52PM +0530, Srivatsa Vaddagiri wrote:
> > * Michael S. Tsirkin [2020-04-28 12:17:57]:
> >
> > > Okay, but how is all this virtio specific? For example, why not allow
> > > separate swiotlbs for any type of device?
> >
On Tue, 28 Apr 2020, Srivatsa Vaddagiri wrote:
> For better security, its desirable that a guest VM's memory is
> not accessible to any entity that executes outside the context of
> guest VM. In case of virtio, backend drivers execute outside the
> context of guest VM and in general will need acces
On Tue, 28 Apr 2020, Jürgen Groß wrote:
> On 28.04.20 09:33, peng@nxp.com wrote:
> > From: Peng Fan
> >
> > When booting xen on i.MX8QM, met:
> > "
> > [3.602128] Unable to handle kernel paging request at virtual address
> > 00272d40
> > [3.610804] Mem abort info:
> > [3.6
1 - 100 of 1357 matches
Mail list logo