[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] RFC: [PATCH 1/3] Enhance platform support for PCI



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.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.