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

[Vijay Kilari <vijay.kilari@xxxxxxxxx>]

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