Re: [libvirt] [Qemu-devel] Modern CPU models cannot be used with libvirt

On Thu, Mar 22, 2012 at 04:30:55PM +0200, Gleb Natapov wrote: Just the fact that it's in a structured key=value format that Qemu itself will interpret before exposing something to the guest. Yes, it's a bit arbitrary. If we could make everything "configuration data", we would (or that's what I think Anthony is pushing for--I hope he will reply and clarify that). Not just "ascii file", but structured (and relatively small) [section]key=value data. If BIOSes were not opaque binary code and could be converted to a small set of config sections and key=values just like cpudefs, one could argue that BIOSes could become configuration data, too. Doing the reverse (transforming simple [section]key=value data to a binary format) would just be silly and wouldn't gain us anything. The point here is that we (Qemu) seem to be moving towards a design where most things are structured "configuration data" that fits on a [section]key=value model, and Qemu just interprets that structured data to build a virtual machine. (That's why I said that perhaps keymaps could become configuration someday. Because maybe they can be converted to a key=value model relatively easily) It's just a bug for you because you disagree with the current design. You can call it rationalization, yes; I am just accepting Anthony's proposal because it's equally good (to me) as what you are proposing. John didn't forget it, he knew that upstream could go in a different direction. The RHEL6 patch description has this: "Note this is intended as an interim work-around for rhel6.0. While the new location of the config file should remain the same, the mechanism to direct qemu to it will likely differ going forward." And one could argue that this only user has wrong expectations and Qemu does it this way by design, and we would be running in circles forever. The only problem for us is that if we keep running in circles, Qemu will keep the current design (or bug, if you want to call it), until Qemu maintainers agree to change the current behavior. I mean: you're right into arguing for it, but somehow I feel I am the wrong person to reply to your arguments, because IMO both approaches are valid. I really hope Anthony will reply to your points, too, or that we discuss that on the next Qemu call. Because if you convince only me, we would gain nothing if the patches implementing the design we agreed with get rejected. It's really a pity that your arguments weren't exposed last week during the Qemu call, when I and Anthony discussed this and agreed on the "compromise solution" I described. Let's try to agree on terminology here: what's "machine configuration"? I understand it as the configuration of a specific virtual machine for a specific Qemu instance (i.e. what we put on the command-line today), I am not talking about machine-types (yet ;). So, considering this definition, machine configuration exists today, there is stuff you can define on a configuration file, and you can give this configuration to -readconfig today. The config file is unfortunately not as powerful as the command-line (some things can be set only on the command-line today), but it exists. Anthony even submitted a RFC series to make the config files as powerful as the command-line, by adding a [system] section. I don't agree completely with that specific implementation, but I agree with the direction it is taking. There are config files today, and they work (but they are not as powerful as the command-line). But the interface is the one I describe below. That would be a valid approach too, but this is just not how the config files work today. We may change it, yes. But today the config file system is based on getting config data from multiple places (/etc/qemu/qemu.conf, extend it with /etc/qemu/target-x86_64.conf, and extend the result with the command-line arguments), instead of using includes. You are right. How the "machine configuration" is going to be loaded is orthogonal to the main question. The main question here is wheter cpudefs should be included on what we call "machine configuration" or not. (agreed?) -- Eduardo