[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...). Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |