[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v5 20/22] xen/arm: ITS: Map ITS translation space
On Tue, 18 Aug 2015 20:14:43 +0100 Julien Grall <julien.grall@xxxxxxxxxx> wrote: > Hi, > > On 27/07/2015 04:12, vijay.kilari@xxxxxxxxx wrote: > > From: Vijaya Kumar K <Vijaya.Kumar@xxxxxxxxxxxxxxxxxx> > > > > ITS translation space contains GITS_TRANSLATOR register > > s/GITS_TRANSLATOR/GITS_TRANSLATOR/ I assume you mean GITS_TRANSLATER? ;-) > > > which is written by device to raise LPI. This space needs > > to mapped to every domain address space for all physical > > ITS available,so that device can access GITS_TRANSLATOR > > Ditto > > > register using SMMU. > > Marc pointed me today that if the processor is writing into > GITS_TRANSLATER it may be able to deadlock the system. > > Reading more closely the spec (8.1.3 IHI0069A), there is undefined > behavior when writing to this register with wrong access size. > > Currently the page table are shared between the processor and the SMMU, > so that means that a domain will be able to deadlock the processor and > therefore the whole platform. Indeed. A CPU should *never* be able to write to the GITS_TRANSLATER register. What would be the meaning anyway? How would a DeviceID be sampled? This is definitely UNPREDICTIBLE territory, and you want to make sure a guest cannot directly write to the HW. > So we should never expose GITS_TRANSLATER into the processor page table. > Which means unsharing some parts if not all of the page tables between > the processor and the SMMU. Agreed. It looks to me like the CPU should only see the the virtual ITS, and nothing else. Thanks, M. -- Jazz is not dead. It just smells funny. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |