All of lore.kernel.org
 help / color / mirror / Atom feed
From: Julien Grall <julien.grall@linaro.org>
To: manish jaggi <manishjaggi.oss@gmail.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: manish.jaggi@caviumnetworks.com, xen-devel <xen-devel@lists.xen.org>
Subject: Re: Few Comments on the Xen SMMU ARM code
Date: Thu, 11 Dec 2014 19:10:52 +0000	[thread overview]
Message-ID: <5489EC3C.6040008@linaro.org> (raw)
In-Reply-To: <CAAiw7J=VLb5tJn18uYZh-SHO9Kb6PsUTiM694BdzRfjKxpv_-Q@mail.gmail.com>

Hello Manish,

On 11/12/14 18:02, manish jaggi wrote:
> On 11 December 2014 at 02:30, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
>> On Wed, 10 Dec 2014, manish jaggi wrote:
>>> Based on my experience with PCI passthrough code merging, below are
>>> some comments:
>>> Both require a change in code
>>>
>>> a) The current code which is non-pci passthrough requires a devices'
>>> device tree node to be associated with smmu node, if that device has
>>> to be assigned to domU.
>>>
>>> In our system there is no platform device which can be passthough. All
>>> devices (including uart) are enumerated using PCI enumeration.
>>> So the device tree looks like
>>>
>>> pcie0 {
>>> }
>>>
>>> smmu {
>>> mmu-masters = <&pcie0 0x100>;
>>> }
>>>
>>> When dom0 boots pcie is assigned to dom0 and a stream ID 0x100 is
>>> created which later conflicts with a valid device enumerated later
>>>
>>> b) Current xen code and linux code used rb_tree with key as dt_node to
>>> locate a device and its smmu. With an enumerated device there is no
>>> such thing. So this would not work.
>>>
>>>
>>> I need your views how PCI passthrough / Non PCI passthrough code can
>>> coexist with the two points mentioned above ?
>>
>> Hello Manish,
>> it is increasingly difficult to reply to your questions without reading
>> any patches or well written design documents.
> 
> Hi Stefano,
> I am sorry about this. I though this mail was discussing on the
> approach already being taken in the current code and I was just
> pointing out issues. I request you to please read the mail one more
> time.

This is not the first time you asked question about the SMMU driver (see
[1]). As I said, I resynced the SMMU driver to use the same as Linux. So
the PCI support should come nicely.

I haven't send anything yet because I'm still clean up the platform
device passthrough code and not happy with some part of the code.
Anyway, I have pushed a branch passthrough-v2.3 on my personal repo:
http://xenbits.xen.org/gitweb/?p=people/julieng/xen-unstable.git

The SMMU drivers should not change too much (assuming the Maintainers
will be happy my change in the IOMMU interface).

Please take a look and let me know if you need to modified on this new
driver or have any question.

> I suggest you send out
>> your series, then we can move forward from there.
>>
> 
> This is the complete smmu.c file which you can refer for PCI
> passthrough (http://pastebin.com/QDX8fpDu)

It's rather difficult to find your changes in a 2000 lines file where
you have lots of debug and commented code. Furthermore you have some
external definition ( such as extern struct pci_dev pci) which is set
somewhere else.

Can you send the whole series as an RFC which all its dependencies (i.e
Linux, GICv3 ITS...)?

> Just FYI this is not a patch, we are still testing on our board and
> can post a patch only after our testing is complete.

I'm lost... I though PCI passthrough was working for you? So what's the
status of the support?

Regards,

[1] http://lists.xen.org/archives/html/xen-devel/2014-11/msg00018.html

-- 
Julien Grall

  reply	other threads:[~2014-12-11 19:10 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-11  2:39 Few Comments on the Xen SMMU ARM code manish jaggi
2014-12-11 10:20 ` Julien Grall
2014-12-11 10:30 ` Stefano Stabellini
2014-12-11 18:02   ` manish jaggi
2014-12-11 19:10     ` Julien Grall [this message]
2014-12-12 11:14     ` Ian Campbell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5489EC3C.6040008@linaro.org \
    --to=julien.grall@linaro.org \
    --cc=manish.jaggi@caviumnetworks.com \
    --cc=manishjaggi.oss@gmail.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.