Re: [Xen-devel] [Draft D] Xen on ARM vITS Handling

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

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.

> > 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.

> 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.

> > 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?


> 
> - Vijay



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