* xen/arm: kernel BUG at /local/home/julien/works/linux/drivers/xen/swiotlb-xen.c:102
@ 2014-11-05 17:32 Julien Grall
2014-11-06 11:46 ` Stefano Stabellini
0 siblings, 1 reply; 6+ messages in thread
From: Julien Grall @ 2014-11-05 17:32 UTC (permalink / raw)
To: Stefano Stabellini; +Cc: Ian Campbell, xen-devel
Hi Stefano,
I've tried your patch series [1] "introduce GNTTABOP_cache_flush"
on midway with non-LPAE (i.e short descriptor) kernel.
While your series should fix the cache flush on this kind of kernel,
I'm still hitting a BUG_ON when I boot a guest (see stack trace [2]).
>From a quick look this is because the dma and physical address don't have
the same size (resp. 64 and 32 bits). Technically xen_bus_to_phys doesn't really
have a meaning on Xen ARM: the address is still a DMA address but we cast it to
a physical address (not sure why?).
It occurs when I use the multi_v7 config (+ XEN) as DOM0. Disabling CONFIG_LPAE
in the config should also do the job.
Regards,
[1] https://lkml.org/lkml/2014/10/27/441
[2] Stack trace:
[ 98.092290] dma 0x2b6769000 paddr 0xb6769000
[ 98.096475] ------------[ cut here ]------------
[ 98.101147] kernel BUG at /local/home/julien/works/linux/drivers/xen/swiotlb-xen.c:102!
[ 98.109219] Internal error: Oops - BUG: 0 [#1] SMP ARM
[ 98.114427] Modules linked in:
[ 98.117554] CPU: 3 PID: 48 Comm: irq/115-highban Not tainted 3.18.0-rc3-00051-g93cf079-dirty #231
[ 98.126493] task: db281680 ti: db40e000 task.ti: db40e000
[ 98.131965] PC is at xen_unmap_single+0xc4/0xc8
[ 98.136563] LR is at xen_unmap_single+0xc4/0xc8
[ 98.141162] pc : [<c04d1640>] lr : [<c04d1640>] psr: 60000013
[ 98.141162] sp : db40fdf0 ip : 00000000 fp : b6769000
[ 98.152793] r10: 00000200 r9 : 00000002 r8 : 00000002
[ 98.158088] r7 : 00000000 r6 : 002b6769 r5 : 00000002 r4 : b6769000
[ 98.164693] r3 : 00000753 r2 : 1af49000 r1 : dbbc73bc r0 : 00000020
[ 98.171282] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
[ 98.178660] Control: 10c5387d Table: 39e3c06a DAC: 00000015
[ 98.184475] Process irq/115-highban (pid: 48, stack limit = 0xdb40e250)
[ 98.191159] Stack: (0xdb40fdf0 to 0xdb410000)
[ 98.195586] fde0: b6769000 00000020 00000000 00000002
[ 98.203833] fe00: db40fe00 db0ea210 00000000 d98a1a80 00000001 00000001 00000002 db0ea210
[ 98.212079] fe20: 00000000 db3e3410 db3f1790 c04d1880 00000200 00000002 00000000 00000016
[ 98.220325] fe40: 0000091e db4100b8 d98a1a80 db410000 00000001 000000b0 00000001 c05cdddc
[ 98.228570] fe60: 00000000 c0262f9c db08c01c db281680 db40e010 db4100b8 db410000 db4116c8
[ 98.236817] fe80: 00000001 c05ce0b0 00000000 00000000 db410000 c05ce478 db410000 db4116c8
[ 98.245068] fea0: 00000000 db410000 e0880100 00000008 00000000 e0880000 00000001 c05e5288
[ 98.253309] fec0: c0c8a994 db40fee8 e0804000 c020897c c041c868 60000013 ffffffff 00000000
[ 98.261554] fee0: db3f1890 0000001f 00000073 00000001 db3f1890 c02836ac db00f7d4 c05e57d0
[ 98.269801] ff00: c05e5788 db3f6340 db00f780 00000000 00000001 db00f780 db3f6340 c02836c8
[ 98.278047] ff20: db3f6360 db40e000 00000000 c02839ec c02838b4 db40e030 00000000 c02837f8
[ 98.286293] ff40: 00000000 db3f6380 00000000 db3f6340 c02838b4 00000000 00000000 00000000
[ 98.294538] ff60: 00000000 c0262358 00000000 00000000 00000000 db3f6340 00000000 00000000
[ 98.302785] ff80: db40ff80 db40ff80 00000000 00000000 db40ff90 db40ff90 db40ffac db3f6380
[ 98.311031] ffa0: c0262280 00000000 00000000 c020f278 00000000 00000000 00000000 00000000
[ 98.319276] ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 98.327522] ffe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
[ 98.335780] [<c04d1640>] (xen_unmap_single) from [<c04d1880>] (xen_swiotlb_unmap_sg_attrs+0x48/0x68)
[ 98.344974] [<c04d1880>] (xen_swiotlb_unmap_sg_attrs) from [<c05cdddc>] (ata_sg_clean+0x8c/0x120)
[ 98.353912] [<c05cdddc>] (ata_sg_clean) from [<c05ce0b0>] (__ata_qc_complete+0x34/0x144)
[ 98.362071] [<c05ce0b0>] (__ata_qc_complete) from [<c05ce478>] (ata_qc_complete_multiple+0xa0/0xd4)
[ 98.371194] [<c05ce478>] (ata_qc_complete_multiple) from [<c05e5288>] (ahci_port_thread_fn+0x138/0x638)
[ 98.380649] [<c05e5288>] (ahci_port_thread_fn) from [<c05e57d0>] (ahci_thread_fn+0x48/0x90)
[ 98.389067] [<c05e57d0>] (ahci_thread_fn) from [<c02836c8>] (irq_thread_fn+0x1c/0x40)
[ 98.396970] [<c02836c8>] (irq_thread_fn) from [<c02839ec>] (irq_thread+0x138/0x174)
[ 98.404693] [<c02839ec>] (irq_thread) from [<c0262358>] (kthread+0xd8/0xf0)
[ 98.411723] [<c0262358>] (kthread) from [<c020f278>] (ret_from_fork+0x14/0x3c)
[ 98.419011] Code: e1a02004 e1a03005 e34c00ad eb0f9c9a (e7f001f2)
--
Julien Grall
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: xen/arm: kernel BUG at /local/home/julien/works/linux/drivers/xen/swiotlb-xen.c:102
2014-11-05 17:32 xen/arm: kernel BUG at /local/home/julien/works/linux/drivers/xen/swiotlb-xen.c:102 Julien Grall
@ 2014-11-06 11:46 ` Stefano Stabellini
2014-11-06 12:25 ` Julien Grall
0 siblings, 1 reply; 6+ messages in thread
From: Stefano Stabellini @ 2014-11-06 11:46 UTC (permalink / raw)
To: Julien Grall; +Cc: xen-devel, Ian Campbell, Stefano Stabellini
Hello Julien,
I didn't manage to reproduce the issue you are seeing but I think you
are right: non-LPAE kernels could get in trouble by calling
xen_bus_to_phys. This problem is not ARM specific per se, but it doesn't
occur on x86 because config XEN depends on X86_32 && X86_PAE.
The following patch should fix the issue:
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index ac5d41b..489620d 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -96,8 +96,6 @@ static inline phys_addr_t xen_bus_to_phys(dma_addr_t baddr)
dma_addr_t dma = (dma_addr_t)pfn << PAGE_SHIFT;
phys_addr_t paddr = dma;
- BUG_ON(paddr != dma); /* truncation has occurred, should never happen */
-
paddr |= baddr & ~PAGE_MASK;
return paddr;
@@ -449,7 +447,7 @@ static void xen_unmap_single(struct device *hwdev, dma_addr_t dev_addr,
BUG_ON(dir == DMA_NONE);
- xen_dma_unmap_page(hwdev, paddr, size, dir, attrs);
+ xen_dma_unmap_page(hwdev, dev_addr, size, dir, attrs);
/* NOTE: We use dev_addr here, not paddr! */
if (is_xen_swiotlb_buffer(dev_addr)) {
On Wed, 5 Nov 2014, Julien Grall wrote:
> Hi Stefano,
>
> I've tried your patch series [1] "introduce GNTTABOP_cache_flush"
> on midway with non-LPAE (i.e short descriptor) kernel.
>
> While your series should fix the cache flush on this kind of kernel,
> I'm still hitting a BUG_ON when I boot a guest (see stack trace [2]).
>
> >From a quick look this is because the dma and physical address don't have
> the same size (resp. 64 and 32 bits). Technically xen_bus_to_phys doesn't really
> have a meaning on Xen ARM: the address is still a DMA address but we cast it to
> a physical address (not sure why?).
>
> It occurs when I use the multi_v7 config (+ XEN) as DOM0. Disabling CONFIG_LPAE
> in the config should also do the job.
>
> Regards,
>
> [1] https://lkml.org/lkml/2014/10/27/441
>
> [2] Stack trace:
>
> [ 98.092290] dma 0x2b6769000 paddr 0xb6769000
> [ 98.096475] ------------[ cut here ]------------
> [ 98.101147] kernel BUG at /local/home/julien/works/linux/drivers/xen/swiotlb-xen.c:102!
> [ 98.109219] Internal error: Oops - BUG: 0 [#1] SMP ARM
> [ 98.114427] Modules linked in:
> [ 98.117554] CPU: 3 PID: 48 Comm: irq/115-highban Not tainted 3.18.0-rc3-00051-g93cf079-dirty #231
> [ 98.126493] task: db281680 ti: db40e000 task.ti: db40e000
> [ 98.131965] PC is at xen_unmap_single+0xc4/0xc8
> [ 98.136563] LR is at xen_unmap_single+0xc4/0xc8
> [ 98.141162] pc : [<c04d1640>] lr : [<c04d1640>] psr: 60000013
> [ 98.141162] sp : db40fdf0 ip : 00000000 fp : b6769000
> [ 98.152793] r10: 00000200 r9 : 00000002 r8 : 00000002
> [ 98.158088] r7 : 00000000 r6 : 002b6769 r5 : 00000002 r4 : b6769000
> [ 98.164693] r3 : 00000753 r2 : 1af49000 r1 : dbbc73bc r0 : 00000020
> [ 98.171282] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
> [ 98.178660] Control: 10c5387d Table: 39e3c06a DAC: 00000015
> [ 98.184475] Process irq/115-highban (pid: 48, stack limit = 0xdb40e250)
> [ 98.191159] Stack: (0xdb40fdf0 to 0xdb410000)
> [ 98.195586] fde0: b6769000 00000020 00000000 00000002
> [ 98.203833] fe00: db40fe00 db0ea210 00000000 d98a1a80 00000001 00000001 00000002 db0ea210
> [ 98.212079] fe20: 00000000 db3e3410 db3f1790 c04d1880 00000200 00000002 00000000 00000016
> [ 98.220325] fe40: 0000091e db4100b8 d98a1a80 db410000 00000001 000000b0 00000001 c05cdddc
> [ 98.228570] fe60: 00000000 c0262f9c db08c01c db281680 db40e010 db4100b8 db410000 db4116c8
> [ 98.236817] fe80: 00000001 c05ce0b0 00000000 00000000 db410000 c05ce478 db410000 db4116c8
> [ 98.245068] fea0: 00000000 db410000 e0880100 00000008 00000000 e0880000 00000001 c05e5288
> [ 98.253309] fec0: c0c8a994 db40fee8 e0804000 c020897c c041c868 60000013 ffffffff 00000000
> [ 98.261554] fee0: db3f1890 0000001f 00000073 00000001 db3f1890 c02836ac db00f7d4 c05e57d0
> [ 98.269801] ff00: c05e5788 db3f6340 db00f780 00000000 00000001 db00f780 db3f6340 c02836c8
> [ 98.278047] ff20: db3f6360 db40e000 00000000 c02839ec c02838b4 db40e030 00000000 c02837f8
> [ 98.286293] ff40: 00000000 db3f6380 00000000 db3f6340 c02838b4 00000000 00000000 00000000
> [ 98.294538] ff60: 00000000 c0262358 00000000 00000000 00000000 db3f6340 00000000 00000000
> [ 98.302785] ff80: db40ff80 db40ff80 00000000 00000000 db40ff90 db40ff90 db40ffac db3f6380
> [ 98.311031] ffa0: c0262280 00000000 00000000 c020f278 00000000 00000000 00000000 00000000
> [ 98.319276] ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> [ 98.327522] ffe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
> [ 98.335780] [<c04d1640>] (xen_unmap_single) from [<c04d1880>] (xen_swiotlb_unmap_sg_attrs+0x48/0x68)
> [ 98.344974] [<c04d1880>] (xen_swiotlb_unmap_sg_attrs) from [<c05cdddc>] (ata_sg_clean+0x8c/0x120)
> [ 98.353912] [<c05cdddc>] (ata_sg_clean) from [<c05ce0b0>] (__ata_qc_complete+0x34/0x144)
> [ 98.362071] [<c05ce0b0>] (__ata_qc_complete) from [<c05ce478>] (ata_qc_complete_multiple+0xa0/0xd4)
> [ 98.371194] [<c05ce478>] (ata_qc_complete_multiple) from [<c05e5288>] (ahci_port_thread_fn+0x138/0x638)
> [ 98.380649] [<c05e5288>] (ahci_port_thread_fn) from [<c05e57d0>] (ahci_thread_fn+0x48/0x90)
> [ 98.389067] [<c05e57d0>] (ahci_thread_fn) from [<c02836c8>] (irq_thread_fn+0x1c/0x40)
> [ 98.396970] [<c02836c8>] (irq_thread_fn) from [<c02839ec>] (irq_thread+0x138/0x174)
> [ 98.404693] [<c02839ec>] (irq_thread) from [<c0262358>] (kthread+0xd8/0xf0)
> [ 98.411723] [<c0262358>] (kthread) from [<c020f278>] (ret_from_fork+0x14/0x3c)
> [ 98.419011] Code: e1a02004 e1a03005 e34c00ad eb0f9c9a (e7f001f2)
>
> --
> Julien Grall
>
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: xen/arm: kernel BUG at /local/home/julien/works/linux/drivers/xen/swiotlb-xen.c:102
2014-11-06 11:46 ` Stefano Stabellini
@ 2014-11-06 12:25 ` Julien Grall
2014-11-06 12:42 ` Stefano Stabellini
0 siblings, 1 reply; 6+ messages in thread
From: Julien Grall @ 2014-11-06 12:25 UTC (permalink / raw)
To: Stefano Stabellini; +Cc: Ian Campbell, xen-devel
On 06/11/2014 11:46, Stefano Stabellini wrote:
> Hello Julien,
Hi Stefano,
> I didn't manage to reproduce the issue you are seeing but I think you
> are right: non-LPAE kernels could get in trouble by calling
> xen_bus_to_phys. This problem is not ARM specific per se, but it doesn't
> occur on x86 because config XEN depends on X86_32 && X86_PAE.
>
> The following patch should fix the issue:
>
>
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index ac5d41b..489620d 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -96,8 +96,6 @@ static inline phys_addr_t xen_bus_to_phys(dma_addr_t baddr)
> dma_addr_t dma = (dma_addr_t)pfn << PAGE_SHIFT;
> phys_addr_t paddr = dma;
>
> - BUG_ON(paddr != dma); /* truncation has occurred, should never happen */
> -
Are you sure that removing this BUG_ON is safe? There is some of place
where we pass a physical address rather than a DMA. See
xen_swiotlb_sync_single.
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: xen/arm: kernel BUG at /local/home/julien/works/linux/drivers/xen/swiotlb-xen.c:102
2014-11-06 12:25 ` Julien Grall
@ 2014-11-06 12:42 ` Stefano Stabellini
2014-11-06 12:56 ` Julien Grall
0 siblings, 1 reply; 6+ messages in thread
From: Stefano Stabellini @ 2014-11-06 12:42 UTC (permalink / raw)
To: Julien Grall; +Cc: xen-devel, Ian Campbell, Stefano Stabellini
On Thu, 6 Nov 2014, Julien Grall wrote:
>
> On 06/11/2014 11:46, Stefano Stabellini wrote:
> > Hello Julien,
>
> Hi Stefano,
>
> > I didn't manage to reproduce the issue you are seeing but I think you
> > are right: non-LPAE kernels could get in trouble by calling
> > xen_bus_to_phys. This problem is not ARM specific per se, but it doesn't
> > occur on x86 because config XEN depends on X86_32 && X86_PAE.
> >
> > The following patch should fix the issue:
> >
> >
> > diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> > index ac5d41b..489620d 100644
> > --- a/drivers/xen/swiotlb-xen.c
> > +++ b/drivers/xen/swiotlb-xen.c
> > @@ -96,8 +96,6 @@ static inline phys_addr_t xen_bus_to_phys(dma_addr_t
> > baddr)
> > dma_addr_t dma = (dma_addr_t)pfn << PAGE_SHIFT;
> > phys_addr_t paddr = dma;
> >
> > - BUG_ON(paddr != dma); /* truncation has occurred, should never happen
> > */
> > -
>
> Are you sure that removing this BUG_ON is safe? There is some of place where
> we pass a physical address rather than a DMA. See xen_swiotlb_sync_single.
Yes, it is safe, but we do need to change those call sites to pass
dev_addr instead, like I have done with unmap_single in the patch I
appended in the last email:
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index ac5d41b..489620d 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -449,7 +447,7 @@ static void xen_unmap_single(struct device *hwdev, dma_addr_t dev_addr,
BUG_ON(dir == DMA_NONE);
- xen_dma_unmap_page(hwdev, paddr, size, dir, attrs);
+ xen_dma_unmap_page(hwdev, dev_addr, size, dir, attrs);
/* NOTE: We use dev_addr here, not paddr! */
if (is_xen_swiotlb_buffer(dev_addr)) {
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: xen/arm: kernel BUG at /local/home/julien/works/linux/drivers/xen/swiotlb-xen.c:102
2014-11-06 12:42 ` Stefano Stabellini
@ 2014-11-06 12:56 ` Julien Grall
2014-11-06 13:01 ` Stefano Stabellini
0 siblings, 1 reply; 6+ messages in thread
From: Julien Grall @ 2014-11-06 12:56 UTC (permalink / raw)
To: Stefano Stabellini; +Cc: Ian Campbell, xen-devel
On 06/11/2014 12:42, Stefano Stabellini wrote:
> On Thu, 6 Nov 2014, Julien Grall wrote:
>>
>> On 06/11/2014 11:46, Stefano Stabellini wrote:
>>> Hello Julien,
>>
>> Hi Stefano,
>>
>>> I didn't manage to reproduce the issue you are seeing but I think you
>>> are right: non-LPAE kernels could get in trouble by calling
>>> xen_bus_to_phys. This problem is not ARM specific per se, but it doesn't
>>> occur on x86 because config XEN depends on X86_32 && X86_PAE.
>>>
>>> The following patch should fix the issue:
>>>
>>>
>>> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
>>> index ac5d41b..489620d 100644
>>> --- a/drivers/xen/swiotlb-xen.c
>>> +++ b/drivers/xen/swiotlb-xen.c
>>> @@ -96,8 +96,6 @@ static inline phys_addr_t xen_bus_to_phys(dma_addr_t
>>> baddr)
>>> dma_addr_t dma = (dma_addr_t)pfn << PAGE_SHIFT;
>>> phys_addr_t paddr = dma;
>>>
>>> - BUG_ON(paddr != dma); /* truncation has occurred, should never happen
>>> */
>>> -
>>
>> Are you sure that removing this BUG_ON is safe? There is some of place where
>> we pass a physical address rather than a DMA. See xen_swiotlb_sync_single.
>
> Yes, it is safe, but we do need to change those call sites to pass
> dev_addr instead, like I have done with unmap_single in the patch I
> appended in the last email:
Ok. I will give a look to modify all the call site.
Regards,
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index ac5d41b..489620d 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -449,7 +447,7 @@ static void xen_unmap_single(struct device *hwdev, dma_addr_t dev_addr,
>
> BUG_ON(dir == DMA_NONE);
>
> - xen_dma_unmap_page(hwdev, paddr, size, dir, attrs);
> + xen_dma_unmap_page(hwdev, dev_addr, size, dir, attrs);
>
> /* NOTE: We use dev_addr here, not paddr! */
> if (is_xen_swiotlb_buffer(dev_addr)) {
>
--
Julien Grall
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: xen/arm: kernel BUG at /local/home/julien/works/linux/drivers/xen/swiotlb-xen.c:102
2014-11-06 12:56 ` Julien Grall
@ 2014-11-06 13:01 ` Stefano Stabellini
0 siblings, 0 replies; 6+ messages in thread
From: Stefano Stabellini @ 2014-11-06 13:01 UTC (permalink / raw)
To: Julien Grall; +Cc: xen-devel, Ian Campbell, Stefano Stabellini
On Thu, 6 Nov 2014, Julien Grall wrote:
> On 06/11/2014 12:42, Stefano Stabellini wrote:
> > On Thu, 6 Nov 2014, Julien Grall wrote:
> > >
> > > On 06/11/2014 11:46, Stefano Stabellini wrote:
> > > > Hello Julien,
> > >
> > > Hi Stefano,
> > >
> > > > I didn't manage to reproduce the issue you are seeing but I think you
> > > > are right: non-LPAE kernels could get in trouble by calling
> > > > xen_bus_to_phys. This problem is not ARM specific per se, but it doesn't
> > > > occur on x86 because config XEN depends on X86_32 && X86_PAE.
> > > >
> > > > The following patch should fix the issue:
> > > >
> > > >
> > > > diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> > > > index ac5d41b..489620d 100644
> > > > --- a/drivers/xen/swiotlb-xen.c
> > > > +++ b/drivers/xen/swiotlb-xen.c
> > > > @@ -96,8 +96,6 @@ static inline phys_addr_t xen_bus_to_phys(dma_addr_t
> > > > baddr)
> > > > dma_addr_t dma = (dma_addr_t)pfn << PAGE_SHIFT;
> > > > phys_addr_t paddr = dma;
> > > >
> > > > - BUG_ON(paddr != dma); /* truncation has occurred, should never happen
> > > > */
> > > > -
> > >
> > > Are you sure that removing this BUG_ON is safe? There is some of place
> > > where
> > > we pass a physical address rather than a DMA. See xen_swiotlb_sync_single.
> >
> > Yes, it is safe, but we do need to change those call sites to pass
> > dev_addr instead, like I have done with unmap_single in the patch I
> > appended in the last email:
>
> Ok. I will give a look to modify all the call site.
No need, I am already writing a new patch to be part of the next version
of my series.
>
> > diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> > index ac5d41b..489620d 100644
> > --- a/drivers/xen/swiotlb-xen.c
> > +++ b/drivers/xen/swiotlb-xen.c
> > @@ -449,7 +447,7 @@ static void xen_unmap_single(struct device *hwdev,
> > dma_addr_t dev_addr,
> >
> > BUG_ON(dir == DMA_NONE);
> >
> > - xen_dma_unmap_page(hwdev, paddr, size, dir, attrs);
> > + xen_dma_unmap_page(hwdev, dev_addr, size, dir, attrs);
> >
> > /* NOTE: We use dev_addr here, not paddr! */
> > if (is_xen_swiotlb_buffer(dev_addr)) {
> >
>
> --
> Julien Grall
>
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-11-06 13:01 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-11-05 17:32 xen/arm: kernel BUG at /local/home/julien/works/linux/drivers/xen/swiotlb-xen.c:102 Julien Grall
2014-11-06 11:46 ` Stefano Stabellini
2014-11-06 12:25 ` Julien Grall
2014-11-06 12:42 ` Stefano Stabellini
2014-11-06 12:56 ` Julien Grall
2014-11-06 13:01 ` Stefano Stabellini
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.