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