On Mon, Oct 05, 2015 at 12:32:00PM +0200, Christoffer Dall wrote: > [cc'ing Mark R. and Shannon for their input on FDT and ACPI]. > > On Mon, Oct 05, 2015 at 11:07:35AM +0100, Peter Maydell wrote: > > On 5 October 2015 at 10:37, Christoffer Dall > > <christoffer.d...@linaro.org> wrote: > > > On Fri, Oct 02, 2015 at 11:53:07PM +0100, Peter Maydell wrote: > > >> * I don't really want to build in a lot of infrastructure into > > >> QEMU to either build the DTC compiler into it or else introduce > > >> a runtime dependency on the dtc binary > > > > > > what level of complexity are we really talking about here? Doesn't QEMU > > > already link against libfdt and doesn't it support exactly what we're > > > trying to do here? > > > > We link against libfdt, but libfdt is for manipulating and creating > > dt binary blobs. As I understand it what sysfs exposes to userspace > > is not a dt binary blob (or fragment thereof) but a bit of dt source. > > libfdt doesn't do parsing of source into blobs; that is done by the > > dtc compiler, which QEMU doesn't currently build and which is set > > up to build only a separate command line binary anyway, not to be > > a utility library for compiling dt sources. > > > > Do correct me if I'm wrong about the sysfs interface -- if it is > > just exposing dt blobs that would be easier to deal with. > > > > I thought there was also /sys/firmware/fdt being the unflattened one > accessible by libfdt, but dtc -I dtb seems to be unhappy parsin this on > my Mustang. > > Mark, can you refresh my memory about this?
/sys/firmware/fdt is the original, unadulterated DTB passed to the kernel, while /sys/firmware/device-tree is the unflattened form which may have had overlays (or perhaps other fixups) applied. For runtime stuff I'd generally expect /sys/firmware/device-tree to be preferable (e.g. if we want to expose some device added by an overlay). We added /sys/firmware/fdt for kexec, as memory reservations are in the DTB header, which doesn't show up in the unflattened tree. > > > I also don't think this is the job of VFIO, assuming there is some > > > better place to do this. I initially thought exposing device properties > > > in some canonical format from sysfs independently from whether the > > > system was booted with ACPI or DT was the right thing to do, but the > > > counter argument to this was essentially that the guest kernel needs the > > > same description as the host kernel and therefore we really have to find > > > a way to pass the HW description bits on to the guest. > > > > So we end up with even more code to pass through ACPI table > > fragments as well :-( > > > > Probaby, yes. But I think it's even worse, because there's no guarantee > you can get at the original firmware data, because it's all from the > DSDT so invoking the initial 'probe' method of the device entry could > theoretically overwrite itself... (If I remember the details > correctly). I don't think you can realistically expose host AML to the guest. Even if it doesn't overwrite itself, it could perform oneshot configuration that breaks if executed repeatedly, try to access otehr bits of ACPI which may or may not be present, call to secure firmware, etc. Mark. _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
