summary refs log tree commit diff stats
path: root/results/classifier/118/virtual/1798434
diff options
context:
space:
mode:
Diffstat (limited to 'results/classifier/118/virtual/1798434')
-rw-r--r--results/classifier/118/virtual/179843443
1 files changed, 43 insertions, 0 deletions
diff --git a/results/classifier/118/virtual/1798434 b/results/classifier/118/virtual/1798434
new file mode 100644
index 000000000..2e52f750e
--- /dev/null
+++ b/results/classifier/118/virtual/1798434
@@ -0,0 +1,43 @@
+virtual: 0.901
+graphic: 0.812
+peripherals: 0.802
+performance: 0.768
+architecture: 0.733
+user-level: 0.731
+device: 0.725
+mistranslation: 0.716
+semantic: 0.708
+kernel: 0.706
+permissions: 0.569
+socket: 0.568
+network: 0.551
+register: 0.542
+vnc: 0.531
+hypervisor: 0.524
+i386: 0.518
+boot: 0.497
+x86: 0.478
+risc-v: 0.422
+files: 0.418
+PID: 0.399
+ppc: 0.382
+arm: 0.373
+debug: 0.357
+VMM: 0.355
+TCG: 0.355
+KVM: 0.307
+assembly: 0.296
+
+[Feature Request] Automatic device configuration discovery
+
+Would it be possible to have a script that enumerates the device tree of a Linux host and generates a qemu command line that would recreate it under emulation? The user would have to customize the arguments (for instance to point to disk image files), but it would take a lot of the guesswork out.
+
+Similarly, is there information that can be gleaned from the kernel build config that would help with configuration?
+
+This is occasionally asked for but unfortunately not in the general case possible. Device trees contain enough information for a guest OS to use the hardware; they do not contain a full description of how the hardware is actually configured and connected together, and they don't say anything about parts of the hardware that are "discoverable" (ie probeable, like PCI). So there isn't enough information to produce a full board model, and the parts that correspond to QEMU command line options (like pluggable devices such as ethernet cards) aren't usually in the DT at all.
+
+The expected workflow goes the other way around -- you start by picking a machine type that QEMU models, and then configure the kernel and use the device tree that is intended for it, in the same way you would if you wanted to get Linux running on a real hardware board.
+
+
+Right, and since QEMU also only supports a limited set of devices, there is no chance that you can mirror an arbitrary host this way. But if you want to convert a host into a VM and do not care whether each and every detail can be mirrored, have a look at http://libguestfs.org/virt-p2v.1.html - that's likely the best solution so far.
+