From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [Draft F] Xen on ARM vITS Handling Date: Fri, 12 Jun 2015 09:52:36 +0100 Message-ID: <1434099156.30003.196.camel@citrix.com> References: <1434015607.30003.137.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Vijay Kilari Cc: manish.jaggi@caviumnetworks.com, Julien Grall , Stefano Stabellini , xen-devel List-Id: xen-devel@lists.xenproject.org On Fri, 2015-06-12 at 14:07 +0530, Vijay Kilari wrote: Please could you trim your quotes to only include the bit you are referring to. Otherwise there is a high chance I will miss a one line comment in the middle of the thousand lines of quoted matter. > > The `GITS_BASER0` will be setup to request sufficient memory for a > > device table consisting of entries of: > > > > struct vdevice_table { > > uint64_t vitt_ipa; > > uint32_t vitt_size; > > uint32_t padding; > > }; > > How about adding valid bit to know if the entry is valid or not? I suggest to use vitt_ipa == INVALID_PADDR to signal this rather than using another bit. > > ## Handling of unrouted/spurious LPIs > > > > Since there is no 1:1 link between a `vLPI` and `pLPI` enabling and > > disabling of phyiscal LPIs cannot be driven from the state of an > > associated vLPI. > > > > Each `pLPI` is routed and enabled during device assignment, therefore > > it is possible to receive a physical LPI which has yet to be routed > > (via a `vITS`) to a `vLPI`. > > Why do we need to enable LPIs during device assignment? > Can't we do it only on LPI configuration update, which is trapped in > Xen as mentioned in 7.8? ( ## Enabling and disabling LPIs) Quoting the first sentence/paragraph of this section: Since there is no 1:1 link between a `vLPI` and `pLPI` enabling and disabling of phyiscal LPIs cannot be driven from the state of an associated vLPI. To expand on that: The vITT can map multiple (vDevice,vEvent) pairs to the same LPI, and each of those (vDevice,vEvent) pairs is related to a different (pDevice,pEvent) which in turn has a unique pLPI associated with it. Thus a vLPI can be associated with more than one pLPI. Enumerating all pLPIs associated with a given vLPI would be expensive (a complete walk of the vITT). In addition if it were possible to do so we would also need to manage enabling/disabling the pLPI in several other places that in vPLI cfg traps, specifically MAPC and MAPD at least. So pLPIs must be routed at device assignment time because in the vLPI configuration table trap there is no mapping back to a single pLPI. Ian.