Re: PCI passthrough issue

[Jean Baptiste Favre <xen-devel@jbfavre.org>]

> >> Ping tests work whatever can be packet size.
> >>
> >> If I understood well what you explain to me, it's now clear that the
> >> problem is somewhat Xen related, isn't it ?
> >
> > It certainly seems that way. I'm not 100% sure that swiotlb=force will
> > have actually made the driver use the swiotlb, it may just have forced
>
> It should have.
>
> > the swiotlb to be allocated. Konrad?
>
> Both. It would allocate it and force all DMA operations to go through
> the bounce buffer.
>
> Let me take a look at the driver itself. Ah, so I had a similar card:
> 3c59x
> which hit the same type of failure way back in 2.6.31 time. It had the
> pci_dma_sync_single_for_cpu(.. PCI_DMA_FROMDEVICE) turned around so it
> would never
> copy properly. But in my tree (2.6.38) the sky driver looks to be
> doing just
> right.. It has PCI_DMA_FROMDEVICE..
>
> Well this looks odd:
>
> 2330         skb = netdev_alloc_skb_ip_align(sky2->netdev, length);
> 2331         if (likely(skb)) {
> 2332                 pci_dma_sync_single_for_cpu(sky2->hw->pdev,
> re->data_addr,
> 2333                                             length,
> PCI_DMA_FROMDEVICE);
> =======>             skb_copy_from_linear_data(re->skb, skb->data,
> length); <====
> 2335                 skb->ip_summed = re->skb->ip_summed;
> 2336                 skb->csum = re->skb->csum;
> 2337                 pci_dma_sync_single_for_device(sky2->hw->pdev,
> re->data_addr,
> 2338                                                length,
> PCI_DMA_FROMDEVICE);
> 2339                 re->skb->ip_summed = CHECKSUM_NONE;
> 2340                 skb_put(skb, length);
> 2341         }
>
> It copies from skb->data (just allocated) to re->skb (seems that the
> re->skb->data
> has been earlier DMA-mapped).
>
> But there is no data in skb->data as we just allocated it? Shouldn't this
> be the other way around? Like this:
>
>
> diff --git a/drivers/net/sky2.c b/drivers/net/sky2.c
> index 7d85a38..37c0631 100644
> --- a/drivers/net/sky2.c
> +++ b/drivers/net/sky2.c
> @@ -2331,7 +2331,7 @@ static struct sk_buff *receive_copy(struct
> sky2_port *sky2,
>      if (likely(skb)) {
>          pci_dma_sync_single_for_cpu(sky2->hw->pdev, re->data_addr,
>                          length, PCI_DMA_FROMDEVICE);
> -        skb_copy_from_linear_data(re->skb, skb->data, length);
> +        skb_copy_from_linear_data(skb, re->skb->data, length);
>          skb->ip_summed = re->skb->ip_summed;
>          skb->csum = re->skb->csum;
>          pci_dma_sync_single_for_device(sky2->hw->pdev, re->data_addr,
>
But, how could a "simple" driver bug automagically appear with Xen and
not as Baremetal ?
And why only with 32bits kernels ?

BTW, I'll try your patch as soon as I can.

> >
> >> I'll be able to continue any tests you want tomorrow.
> >> Do you still need me to compile domU kernel with "CONFIG_DMA_API_DEBUG"
> >> enabled ?
> >
> > Yes please.
> >
> >> If so, what tools will I need to get debug informations ?
> >
> > Uh, Konrad?
>
> Here, try this patch. Run it under baremetal and Xen and we can
> compare the
> outputs .. but I think the issue here is not off mis-using the DMA API but
> rather a driver bug.
OK, so if you first patch does not solve problem, I'll compile this one
as kernel module and load it, both on 32bits Baremetal and in 32bits DomU

Regards,
JB