[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [Draft D] Xen on ARM vITS Handling
On Fri, Jun 5, 2015 at 6:58 PM, Ian Campbell <ian.campbell@xxxxxxxxxx> wrote: > On Fri, 2015-06-05 at 18:11 +0530, Vijay Kilari wrote: > >> >> Here device table memory allocated by guest is used to lookup for the >> >> device. >> >> Why can't we avoid using the guest memory all together and just only >> >> emulate >> >> read and write of GITS_BASER0. >> > >> > Emulate how? All as GITS_BASERn.Valid == 0 for all? >> >> Yes, this avoids guest allocating device table for ITS which >> is not used. > > In this design the device table from the guest _is_ used though. > > If you have another design in mind which doesn't require this then > please propose it. With below discussion is to avoid using guest device table > >> > As an alternative I suppose we could e.g. insert dummy struct its_device >> > entries into the per-domain virtual deviceid mapping table in response >> > to `MPAD` requests for guest invented devices. Then we would need a >> > mechanism to stop a guest from populating all 2^32 entries in the tree >> > (which would use a lot of Xen guest RAM) and ideally we would want to >> > avoid allocating dummy struct its_device during emulation. >> >> If dom0 is inventing all the devices in the platform and Xen is preallocating >> memory for its_device struct that are added using PHYSDEV_add_device op, >> there is will be no chance of domain allocating 2^32 devices. > > (ITYM PHYSDEVOP_pci_device_add) > > The invented device ids here are the sort discussed in "ITS > Configuration" as being used for ITS completion notification, and which > therefore do not correspond to any real device at all. A domU might make > up an arbitrary device ID, unused by any device which it can see, in > order to use with an INT command on its vits in order to get a > completion interrupt. > > I hadn't imagined requiring the guest to call PHYSDEVOP_pci_device_add > for such phantom devices just in order to be able to use them with the > INT command, and I don't think you were suggesting this anyway. I'm not > sure what the implications of extending that to domUs being allowed to > register invented "phantom" devices, but on the face of it I don't think > it is a good idea. What I mean is we don't need domU's to allow and register phantom/dummy devices used for INT command with PHYSDEVOP_pci_device_add. Let xen mark those phantom devices added using MAPD as dummy and just emulate and does not translate ITS commands for these devices. > >> So deviceid of any MAPD command for all the guests should be have been >> within pre-identified list. > > I don't think that is true for a domU, not necessarily for a dom0 given > that any device id can be used with INT. If the INT command is with valid device (not phantom) then Xen can translate and send to ITS hardware > >> > Perhaps each guest could have a small pool of "invented its_devices" >> > allocated at start of day (small == say, 4) which could be inserted into >> > the device table on MAPD, once they are all used further MAPD commands >> > for invented devices would be ignored (this assumes that most guests >> > will only want one such device for completion purposes), which also >> > solves the problem of filling the tree completely (or does it: a >> > sequence of MAPD commands setting and clearing all 2^32 devices might >> > cause us to populate the whole tree). >> >> If guest is creating this new device for its completion >> INT purpose by sending MAPD command, then Xen can create dummy device. >> >> I think we can limit number of dummy devices that guest can create to >> small (2 or 4) >> and number of vectors say 32. Xen can mark this devices as dummy and >> allow all MAPVI/MAPI commands >> on this device, but does not translate to physical ITS commands. > > Nothing in this iteration of the design translates any virtual command > into any physical one. > >> Also >> multiple guests can create dummy device with the same deviceID for which >> Xen cannot translate. > > >> >> On receiving INT command, Xen will just inject LPI mapped for the (device, >> ID) >> (INT device, ID) to domain. So effectively no physical commands are _not_ >> sent >> to ITS hardware that are related to dummy devices. > > I can't parse this last sentence, it seems to have an unintentional > double negative? Sorry. I correct it as "So effectively no physical commands are sent to ITS hardware that are related to dummy/phantom devices" > > >> >> - Vijay > > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |