All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Campbell <ian.campbell@citrix.com>
To: Julien Grall <julien.grall@citrix.com>
Cc: manish.jaggi@caviumnetworks.com,
	Julien Grall <julien.grall@linaro.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Vijay Kilari <vijay.kilari@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Draft C] Xen on ARM vITS Handling
Date: Mon, 1 Jun 2015 14:45:01 +0100	[thread overview]
Message-ID: <1433166301.15036.210.camel@citrix.com> (raw)
In-Reply-To: <556C4F18.2060205@citrix.com>

On Mon, 2015-06-01 at 13:24 +0100, Julien Grall wrote:
> On 01/06/15 13:11, Ian Campbell wrote:
> >>> ### Device ID (`ID`)
> >>>
> >>> This parameter is used by commands which manage a specific device and
> >>> the interrupts associated with that device. Checking if a device is
> >>> present and retrieving the data structure must be fast.
> >>>
> >>> The device identifiers may not be assigned contiguously and the maximum
> >>> number is very high (2^32).
> >>>
> >>> XXX In the context of virtualised device ids this may not be the case,
> >>> e.g. we can arrange for (mostly) contiguous device ids and we know the
> >>> bound is significantly lower than 2^32
> >>>
> >>> Possible efficient data structures would be:
> >>>
> >>> 1. List: The lookup/deletion is in O(n) and the insertion will depend
> >>>    if the device should be sorted following their identifier. The
> >>>    memory overhead is 18 bytes per element.
> >>> 2. Red-black tree: All the operations are O(log(n)). The memory
> >>>    overhead is 24 bytes per element.
> >>>
> >>> A Red-black tree seems the more suitable for having fast deviceID
> >>> validation even though the memory overhead is a bit higher compare to
> >>> the list.
> >>
> >> When PHYSDEVOP_pci_device_add is called, memory for its_device structure
> >> and other needed structure for this device is allocated added to RB-tree
> >> with all necessary information
> > 
> > Sounds like a reasonable time to do it. I added something based on your
> > words.
> 
> Hmmm... The RB-tree suggested is per domain not the host and indexed
> with the vDevID.

I added "The `ID` is per domain and therefore the datastructure should
be too." before "Possible efficient..."

> This is the only way to know quickly if the domain is able to use the
> device and retrieving a device. Indeed, the vDevID won't be equal to the
> pDevID as the vBDF will be different to the pBDF.
> 
> PHYSDEVOP_pci_device_add is to ask Xen managing the PCI device. At that
> time we don't know to which domain the device will be passthrough.

Yes, I suppose we can allocate at PHYSDEVOP_pci_device_add time, but
linking it into the R-B tree will have to happen at assignment time.

This section now ends:

        When `PHYSDEVOP_pci_device_add` is called, memory for its_device
        structure and other needed structure for this device is allocated.
        
        When `XEN_DOMCTL_assign_device` is called the device will be added to
        the per domain RB-tree with all necessary information.

Ian.

  reply	other threads:[~2015-06-01 13:45 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-27 11:48 [Draft C] Xen on ARM vITS Handling Ian Campbell
2015-05-27 16:44 ` Vijay Kilari
2015-05-29 14:06   ` Julien Grall
2015-06-01 13:36     ` Ian Campbell
2015-06-02 10:46       ` Julien Grall
2015-06-02 11:09         ` Ian Campbell
2015-06-01 12:11   ` Ian Campbell
2015-06-01 12:24     ` Julien Grall
2015-06-01 13:45       ` Ian Campbell [this message]
2015-06-03  7:25       ` Vijay Kilari
2015-06-03  8:45         ` Ian Campbell
2015-05-29 13:40 ` Julien Grall
2015-06-01 13:12   ` Ian Campbell
2015-06-01 15:29     ` Julien Grall
2015-06-02  9:41       ` 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=1433166301.15036.210.camel@citrix.com \
    --to=ian.campbell@citrix.com \
    --cc=julien.grall@citrix.com \
    --cc=julien.grall@linaro.org \
    --cc=manish.jaggi@caviumnetworks.com \
    --cc=stefano.stabellini@citrix.com \
    --cc=vijay.kilari@gmail.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.