Re: [Xen-devel] [PATCH v3 12/13] xen/arm: Add the property "protected-devices" in the hypervisor node

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

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