From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: RFC: [PATCH 1/3] Enhance platform support for PCI Date: Wed, 25 Feb 2015 10:20:03 +0000 Message-ID: <1424859603.20243.71.camel@citrix.com> References: <54E71BDE.5020106@caviumnetworks.com> <54E7229C.7000301@linaro.org> <54E72452.3090801@caviumnetworks.com> <54E72688.9010005@linaro.org> <54E729F1.6000804@caviumnetworks.com> <54E73010.2050902@caviumnetworks.com> <1424439941.30924.243.camel@citrix.com> <54E74135.4040302@caviumnetworks.com> <1424443185.30924.268.camel@citrix.com> <54EB0813.20909@caviumnetworks.com> <54EB0B7D.6060909@linaro.org> <54EB1401.2050609@caviumnetworks.com> <54EB440C.9010806@linaro.org> <54EB5F86.40607@caviumnetworks.com> <54EB9E13.7060802@linaro.org> <54EBC47E.4040801@caviumnetworks.com> <54EC8007.1090405@linaro.org> <54ED345C.8020902@caviumnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <54ED345C.8020902@caviumnetworks.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Manish Jaggi Cc: prasun.kapoor@cavium.com, "Kumar, Vijaya" , Julien Grall , xen-devel@lists.xen.org, "Stefano Stabellini (Stefano.Stabellini@citrix.com)" , Jan Beulich List-Id: xen-devel@lists.xenproject.org On Wed, 2015-02-25 at 08:03 +0530, Manish Jaggi wrote: > On 24/02/15 7:13 pm, Julien Grall wrote: > > On 24/02/15 00:23, Manish Jaggi wrote: > >>> Because you have to parse all the device tree to remove the reference > >>> to the second ITS. It's pointless and can be difficult to do it. > >>> > >> Could you please describe the case where it is difficult > > You have to parse every node in the device tree and replace the > > msi-parent properties with only one ITS. > Thats the idea. > > > >>> If you are able to emulate on ITS, you can do it for multiple one. > >> keeping it simple and similar across dom0/domUs > >> Consider a case where a domU is assigned two PCI devices which are > >> attached to different nodes. (Node is an entity having its own cores are > >> host controllers). > > The DOM0 view and guest view of the hardware are different. > > > > In the case of DOM0, we want to expose the same hardware layout as the > > host. So if there is 2 ITS then we should expose the 2 ITS. > AFAIK Xen has a microkernel design and timer/mmu/smmu/gic/its are > handled by xen and a virtualized interface is provided to the guest. So > if none of SMMU in the layout of host is presented to dom0 the same can > be valid for multiple ITS. SMMU is one of the things which Xen hides from dom0, for obvious reasons. Interrupts are exposed to dom0 in a 1:1 manner. AFAICT there is no reason for ITS to differ here. Since dom0 needs to be able to cope with being able to see all of the host host I/O devices (in the default no-passthrough case), it is possible, if not likely, that it will need the same amount of ITS resources (i.e. numbers of LPIs) as the host provides. > > In the case of the Guest, we (Xen) controls the memory layout. > For Dom0 as well. Not true. For dom0 the memory layout is determined by the host memory layout. The MMIO regions are mapped through 1:1 and the RAM is a subset of the RAM regions of the host physical address space (often in 1:1, but with sufficient h/w support this need not be the case). > > Therefore > > we can expose only one ITS. > If we follow 2 ITS in dom0 and 1 ITS in domU, how do u expect the Xen > GIC ITS emulation driver to work. > It should check that request came from a dom0 handle it differently. I > think this would be *difficult*. I don't think so. If the vITS is written to handle multiple instances (i.e. in a modular way, as it should be) then it shouldn't matter whether any given domain has 1 or many vITS. The fact that dom0 may have one or more and domU only (currently) has one then becomes largely uninteresting. Ian.