[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v2 00/21] xen/arm: Add support for non-pci passthrough

On Wed, 2014-09-10 at 13:45 +0200, Christoffer Dall wrote:
> On Wed, Sep 10, 2014 at 12:51 PM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> 
> wrote:
> > On Wed, 2014-09-10 at 11:22 +0200, Christoffer Dall wrote:
> >>   How does a user
> >> know which physical address in Xen's physical address space needs to
> >> be remapped based on the hardware description language for Dom0?
> >
> > This is an interesting question. The short answer for platform device
> > type things is "they just know" (they presumably have datasheets etc).
> > But I think the underlying question here is whether they are given in PA
> > space or dom0 IPA space, right?
> >
> re. the underlying question, yes.
> For platform devices, I think the "they just know" doesn't really
> work.

It does "work" in the sense that it is usable to achieve a user's aims.
It may not "work" in the sense that it is not as convenient to use as it
could be.

>   There must be a way for user space to determine the IO
> addresses and IRQ numbers for a platform device, I just think it
> should be completely decoupled from ACPI and DT.

You are right that it would be good to have something better, but that
is not going to happen for 4.5.

I think you got my point by the end of the mail so I won't belabour it
again ;-)

> > So I think we can continue to treat these
> > things as proper physical addresses and don't need to introduce variants
> > of the hypercalls which work in terms of IPAs (or you could argue that
> > they already do and the translation is currently a nop).
> fair enough, I guess for passthrough it's valid to always specify
> things in Dom0's address/number space, because Xen already knows about
> the translations to do the right thing....

Yes, I think if we ever took away 1:1 MMIO mappings from dom0 we would
probably end up retconning things to have always been in dom0 IPA
addressing and fixup the fallout from that in the hypervisor as part of
that shift.

That last paragraph does make me question 05/21 "xen/arm: follow-up to
allow DOM0 manage IRQ and MMIO" which removes the dom0 mapping of
devices which have been "marked for passthrough" though, since it would
break this model.

I think it should be sufficient to mark the devices as disabled to dom0
in the DT (or the ACPI equivalent) but still MMIO map them in the normal
way. This is consistent with e.g. pciback.hide= on x86 and avoids
special casing these devices wrt having perms but not mappings. I'm not
sure what the argument was for removing the MMIO mapping from dom0 (it
seemed to make sense in isolation when I read the patch, but I'm now
wondering about it...).


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.