[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC 12/19] xen/passthrough: iommu_deassign_device_dt: By default reassign device to nobody
On 07/03/2014 03:04 PM, Ian Campbell wrote: > On Thu, 2014-07-03 at 14:51 +0100, Julien Grall wrote: >> On 07/03/2014 02:42 PM, Ian Campbell wrote: >>> On Thu, 2014-07-03 at 14:01 +0100, Julien Grall wrote: >>>> On 07/03/2014 01:53 PM, Ian Campbell wrote: >>>>> On Thu, 2014-07-03 at 13:07 +0100, Julien Grall wrote: >>>>>>>> If Xen reassigns the device to "nobody", it may receive some >>>>>>>> global/context >>>>>>>> fault because the transaction has failed (indeed the context has been >>>>>>>> marked invalid). >>>>>>> >>>>>>> Can you describe here what happen in this case (I presume Xen tears down >>>>>>> the iommu to quiesce them somehow?) >>>>>> >>>>>> The SMMU drivers will mark the different Context Bank, S2CR, SMR as >>>>>> invalid. If the device is attempt to access the memory then, we will >>>>>> receive an interrupt in Xen. >>>>>> >>>>>> Actually it's only happen once, if the device is still enabled when the >>>>>> domain is shutdown. >>>>> >>>>> My concern was with getting a storm of such interrupts after this point. >>>>> If it only happens once and any subsequent ones are damped by some means >>>>> then great. >>>> >>>> I guess, it can happen with a buggy device trying to access memory >>>> alone. But I don't think we should care about this case. >>> >>> Ideally such a device wouldn't be able to DoS the rest of the system. >>> >>> Does the SMMU not have a bit to say: deny all MMIO from this context >>> without raising an exception? >> >> AFAIK, no. We receive a transaction fault via the global interrupt. If >> we disable this interrupt we also disable potentially helpful message >> when the register are misconfigured. > > That seems like something of a hardware shortcoming. > > It might be worth asking one of the ARM guys what we should do with a > device which won't shut up. I will send an email to Marc & Will. -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |