[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v3 12/13] xen/arm: Add the property "protected-devices" in the hypervisor node
On Fri, 2014-04-04 at 12:01 +0100, Julien Grall wrote: > On 04/04/2014 11:48 AM, Ian Campbell wrote: > > On Fri, 2014-04-04 at 11:39 +0100, Julien Grall wrote: > >> On 04/04/2014 11:28 AM, Ian Campbell wrote: > >>> On Fri, 2014-04-04 at 11:25 +0100, Julien Grall wrote: > >>>> On 04/04/2014 10:40 AM, Ian Campbell wrote: > >>>> > >>>>> We really need to be able to manage this transition in a compatible way, > >>>>> that means new kernels working on old hypervisors as well as old kernels > >>>>> working on new hypervisors (it's obviously fine for this case to bounce > >>>>> when it doesn't need to). > >>>> > >>>> It's not possible because a same platform can have both protected and > >>>> non-protected devices. The Linux has to know in some way if the DMA has > >>>> to be program with IPA or PA. > >>> > >>> Then there must be a negotiation between Xen and the Linux kernel so Xen > >>> can know which case to apply. > >>> > >>> e.g. if the kernel does not advertise support for protected devices then > >>> Xen must act as if no IOMMU was present. > >> > >> How the kernel can say "I'm supporting IOMMU"? New hypercall? > > > > On x86 we use the ELF notes to communicate it at build time. We don't > > currently have a similar mechanism under ARM but perhaps we need to > > invent one now. > > > > There is also __HYPERVISOR_vm_assist which is/was used on PV x86 to > > signal these sorts of things, if its not too late. > > > >> Xen has to program the IOMMU quite early (e.g before Linux is booting > >> and use the protected device). > > > > In that case an ELF note type solution might be the only option. > > > > However, since this stuff only comes to matter when the guest comes to > > do grant mapping it might be that we can defer until runtime and require > > that a modern kernel calls vm_assist before making any grant calls. If > > it doesn't then it is assumed to be unable to cope with the iommu. > > Using vm_assist means we can't anymore denied access to invalid > transaction by default. It sounds like we want to completely disable the > IOMMU, because in this case passthrough should not be enabled. We could enable both of those things only at the point where vm_assist was called. And yes, if the dom0 kernel isn't capable of doing stuff with the IOMMU enable we should turn off passthrough too. > Futhermore, I can't predict what would happen if the device is used and > the kernel decides to call vm_assist (e.g protect devices). I suppose we > can break the device at this time. I think we can reasonably require that vm_assist be called super early, i.e. before any DMA operations occur, in Linux terms I think early_initcall(xen_guest_init) is likely early enough, or we could move xen_guestr_init even sooner. We also have the option of a build time feature flag in the image itself like on x86. It is likely that going forward we will have other cases where we wished we had such a thing so getting it in place now would be useful. > It's not possible in Xen to know if the decide is used or not. "the decide"? > > >> Backporting my patch series to support protected devices is not a big > >> deal. What about disabling IOMMU by default on ARM until a good support > >> is made in Linux? > > > > I'd rather avoid this if at all possible, upgrading Xen is not supposed > > to require new dom0 kernel features and it is hard to describe "support > > for protected devices" as a bug fix. > > But we can chose to disable IOMMU by default on ARM. And the user will > have to decide if it's safe or not to use IOMMU. That's a cop out and a rubbish user experience going forward. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |