On 5 October 2015 at 10:37, Christoffer Dall <christoffer.dall@xxxxxxxxxx> 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 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 :-( >> (except "don't do device passthrough for platform devices, insist >> on a real bus like PCI"...) >> > While I appreciate the simplicity of this solution from our > (maintainers') point of view, I still see the latter point as relatively > moot. We have hardware with 10G platform ethernet devices that people > want to do device assignment on already, and I think we should try to > find a reasonable set of boundaries for setups that we can support > upstream instead of this becoming a black hole of derivative code bases > to do this sort of thing. Yeah, speaking more seriously I agree we do need to do something here. It's just all irritatingly awkward... thanks -- PMM _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
