Re: [Qemu-devel] [PATCH v3 00/26] q35 qemu support
On 22.10.2012 19:37, Anthony Liguori wrote: [] IOW: q35-next - bleeding edge version of code. No compatibility guarantee q35-0.1 - if we decide we want to have a tech preview of q35 that's incomplete but will be supported for compat q35-1.0 - the first complete release of q35 with full compat support Make it q35-1.3 instead - to match the version of qemu where it appeared (if it will go into 1.3 ofcourse; if not, it will be 1.4 or something). And maybe q35-0.1.3 if it will go into 1.3 in a tech preview form. Just to avoid confusion. /mjt
Re: [Qemu-devel] [PATCH v3 00/26] q35 qemu support
On Mon, Oct 22, 2012 at 07:58:32AM +0200, Gerd Hoffmann wrote: Hi, Would it make sense to temporarily rename the machine type e.g. pc-q35-experimental to stress it's not fully supported? I don't think this is needed as piix will continue to be the default. Well q35 is not yet 100% ready. I'm looking for some way in which we can signal libvirt and other users when it's ready, while merging some bits to reduce the maintainance load of maintaining a q35 fork. It will also cause trouble with libvirt when pc-q35-experimental goes away some day. cheers, Gerd The point was to hide it from libvirt. libvirt should support pc-q35 not pc-q35-experimental, then it will not cause trouble. -- MST
Re: [Qemu-devel] [PATCH v3 00/26] q35 qemu support
On 10/22/12 12:08, Michael S. Tsirkin wrote: On Mon, Oct 22, 2012 at 07:58:32AM +0200, Gerd Hoffmann wrote: Hi, Would it make sense to temporarily rename the machine type e.g. pc-q35-experimental to stress it's not fully supported? I don't think this is needed as piix will continue to be the default. Well q35 is not yet 100% ready. I know. The point was to hide it from libvirt. libvirt should support pc-q35 not pc-q35-experimental, then it will not cause trouble. You'll not going to hide it that way. Libvirt will just 'qemu -M ?' where q35 will show up even if you rename it to be postfixed -experimental. But as long as 'pc' continues to be the default the causal user will never ever notice q35 is there, at least not with virt-manager (dunno about boxes) as there is simply no gui way to pick the machine type. You'll have to explicitly virsh edit $guest to switch it to q35. So I'm not sure what you are worryed about. But in any case this needs discussion with the libvirt folks to make sure it will actually work as intended. /me tends to think a experimental bit in machine_info (which is then printed by 'qemu -M ?' and the QOM-version of that) is more useful than playing tricks with the name. cheers, Gerd
Re: [Qemu-devel] [PATCH v3 00/26] q35 qemu support
On Mon, Oct 22, 2012 at 12:37:39PM +0200, Gerd Hoffmann wrote: On 10/22/12 12:08, Michael S. Tsirkin wrote: On Mon, Oct 22, 2012 at 07:58:32AM +0200, Gerd Hoffmann wrote: Hi, Would it make sense to temporarily rename the machine type e.g. pc-q35-experimental to stress it's not fully supported? I don't think this is needed as piix will continue to be the default. Well q35 is not yet 100% ready. I know. The point was to hide it from libvirt. libvirt should support pc-q35 not pc-q35-experimental, then it will not cause trouble. You'll not going to hide it that way. Libvirt will just 'qemu -M ?' where q35 will show up even if you rename it to be postfixed -experimental. But as long as 'pc' continues to be the default the causal user will never ever notice q35 is there, at least not with virt-manager (dunno about boxes) as there is simply no gui way to pick the machine type. You'll have to explicitly virsh edit $guest to switch it to q35. So I'm not sure what you are worryed about. I worry about need to maintain bug for bug compatibility on the unlikely chance that the work to complete it gets delayed and we release it in an unready state. But in any case this needs discussion with the libvirt folks to make sure it will actually work as intended. /me tends to think a experimental bit in machine_info (which is then printed by 'qemu -M ?' and the QOM-version of that) is more useful than playing tricks with the name. cheers, Gerd I agree it's best to ask libvirt folks what's the right way to hide a machine type from it. Add a flag so it's not listed in -M ? ? Jason, do you know? -- MST
Re: [Qemu-devel] [PATCH v3 00/26] q35 qemu support
On Fri, Oct 19, 2012 at 04:43:25PM -0400, Jason Baron wrote: Hi, Qemu bits for q35 support, I'm posting the seabios changes separately. The patches require '-M pc_q35' and -L 'seabios dir with q35 changes' on the qemu command line. Hopefully, we can make it the default for x86 at some future point when we feel comfortable with it. Some patches have multiple copyright sections. I realize this is because you copied code from other files but think it would be better to simply keep the original license in this case, just extending list of copyright holders. -- MST
Re: [Qemu-devel] [PATCH v3 00/26] q35 qemu support
On 10/22/2012 07:16 AM, Michael S. Tsirkin wrote: I worry about need to maintain bug for bug compatibility on the unlikely chance that the work to complete it gets delayed and we release it in an unready state. But in any case this needs discussion with the libvirt folks to make sure it will actually work as intended. /me tends to think a experimental bit in machine_info (which is then printed by 'qemu -M ?' and the QOM-version of that) is more useful than playing tricks with the name. cheers, Gerd I agree it's best to ask libvirt folks what's the right way to hide a machine type from it. Add a flag so it's not listed in -M ? ? For qemu 1.3, libvirt will NOT be reading '-M ?', but instead calling the 'query-machines' QMP command. If you want a machine to be avoided by libvirt, then perhaps it is best to augment the MachineInfo QMP datatype to add an optional field that says whether a particular machine type is stable enough for libvirt's use. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH v3 00/26] q35 qemu support
On Mon, Oct 22, 2012 at 07:00:56AM -0600, Eric Blake wrote: On 10/22/2012 07:16 AM, Michael S. Tsirkin wrote: I worry about need to maintain bug for bug compatibility on the unlikely chance that the work to complete it gets delayed and we release it in an unready state. But in any case this needs discussion with the libvirt folks to make sure it will actually work as intended. /me tends to think a experimental bit in machine_info (which is then printed by 'qemu -M ?' and the QOM-version of that) is more useful than playing tricks with the name. cheers, Gerd I agree it's best to ask libvirt folks what's the right way to hide a machine type from it. Add a flag so it's not listed in -M ? ? For qemu 1.3, libvirt will NOT be reading '-M ?', but instead calling the 'query-machines' QMP command. If you want a machine to be avoided by libvirt, then perhaps it is best to augment the MachineInfo QMP datatype to add an optional field that says whether a particular machine type is stable enough for libvirt's use. Or just hide this machine type from the query-machines command? -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org
Re: [Qemu-devel] [PATCH v3 00/26] q35 qemu support
On 10/22/2012 08:23 AM, Michael S. Tsirkin wrote: On Mon, Oct 22, 2012 at 07:00:56AM -0600, Eric Blake wrote: On 10/22/2012 07:16 AM, Michael S. Tsirkin wrote: I worry about need to maintain bug for bug compatibility on the unlikely chance that the work to complete it gets delayed and we release it in an unready state. But in any case this needs discussion with the libvirt folks to make sure it will actually work as intended. /me tends to think a experimental bit in machine_info (which is then printed by 'qemu -M ?' and the QOM-version of that) is more useful than playing tricks with the name. cheers, Gerd I agree it's best to ask libvirt folks what's the right way to hide a machine type from it. Add a flag so it's not listed in -M ? ? For qemu 1.3, libvirt will NOT be reading '-M ?', but instead calling the 'query-machines' QMP command. If you want a machine to be avoided by libvirt, then perhaps it is best to augment the MachineInfo QMP datatype to add an optional field that says whether a particular machine type is stable enough for libvirt's use. Or just hide this machine type from the query-machines command? That would probably work, as well. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH v3 00/26] q35 qemu support
On 22.10.2012, at 16:03, Eric Blake wrote: On 10/22/2012 08:23 AM, Michael S. Tsirkin wrote: On Mon, Oct 22, 2012 at 07:00:56AM -0600, Eric Blake wrote: On 10/22/2012 07:16 AM, Michael S. Tsirkin wrote: I worry about need to maintain bug for bug compatibility on the unlikely chance that the work to complete it gets delayed and we release it in an unready state. But in any case this needs discussion with the libvirt folks to make sure it will actually work as intended. /me tends to think a experimental bit in machine_info (which is then printed by 'qemu -M ?' and the QOM-version of that) is more useful than playing tricks with the name. cheers, Gerd I agree it's best to ask libvirt folks what's the right way to hide a machine type from it. Add a flag so it's not listed in -M ? ? For qemu 1.3, libvirt will NOT be reading '-M ?', but instead calling the 'query-machines' QMP command. If you want a machine to be avoided by libvirt, then perhaps it is best to augment the MachineInfo QMP datatype to add an optional field that says whether a particular machine type is stable enough for libvirt's use. Or just hide this machine type from the query-machines command? That would probably work, as well. You would still want the testing from users behind libvirt, so hiding is not good. Hiding by default with an experimental tag would probably be the best. Alex
Re: [Qemu-devel] [PATCH v3 00/26] q35 qemu support
Michael S. Tsirkin m...@redhat.com writes: On Mon, Oct 22, 2012 at 12:37:39PM +0200, Gerd Hoffmann wrote: On 10/22/12 12:08, Michael S. Tsirkin wrote: On Mon, Oct 22, 2012 at 07:58:32AM +0200, Gerd Hoffmann wrote: Hi, Would it make sense to temporarily rename the machine type e.g. pc-q35-experimental to stress it's not fully supported? I don't think this is needed as piix will continue to be the default. Well q35 is not yet 100% ready. I know. The point was to hide it from libvirt. libvirt should support pc-q35 not pc-q35-experimental, then it will not cause trouble. You'll not going to hide it that way. Libvirt will just 'qemu -M ?' where q35 will show up even if you rename it to be postfixed -experimental. But as long as 'pc' continues to be the default the causal user will never ever notice q35 is there, at least not with virt-manager (dunno about boxes) as there is simply no gui way to pick the machine type. You'll have to explicitly virsh edit $guest to switch it to q35. So I'm not sure what you are worryed about. I worry about need to maintain bug for bug compatibility on the unlikely chance that the work to complete it gets delayed and we release it in an unready state. But in any case this needs discussion with the libvirt folks to make sure it will actually work as intended. /me tends to think a experimental bit in machine_info (which is then printed by 'qemu -M ?' and the QOM-version of that) is more useful than playing tricks with the name. cheers, Gerd I agree it's best to ask libvirt folks what's the right way to hide a machine type from it. Add a flag so it's not listed in -M ? ? Jason, do you know? We don't need to hide it from libvirt. What I'd suggest is that for q35, we don't introduce QEMU versioned machine types but instead provide a machine-level version. IOW: q35-next - bleeding edge version of code. No compatibility guarantee q35-0.1 - if we decide we want to have a tech preview of q35 that's incomplete but will be supported for compat q35-1.0 - the first complete release of q35 with full compat support I think we should also alias 'q35' to 'q35-next'. Regards, Anthony Liguori -- MST
Re: [Qemu-devel] [PATCH v3 00/26] q35 qemu support
On Fri, Oct 19, 2012 at 04:43:25PM -0400, Jason Baron wrote: Hi, Qemu bits for q35 support, I'm posting the seabios changes separately. The patches require '-M pc_q35' and -L 'seabios dir with q35 changes' on the qemu command line. Hopefully, we can make it the default for x86 at some future point when we feel comfortable with it. The current patches have been tested with basic install testing and memory testing on f16, f17, windows 7 and windows 8. They can be run on the various BSD flavors by adding a 'piix4-ide' device to the pci bus. ie: -device piix4-ide. Patches have also been reported to work with a small dsdt change on OSX 10.6 as well. I've dropped the ahci migration bits, which means q35 is not migratable at the moment. I simply haven't had time to make them more complete yet. I'm hoping that we'll come to some agreement on the minimal functionality required for q35 to be merged. Git trees: git://github.com/jibaron/q35-qemu.git git://github.com/jibaron/q35-seabios.git Notes: I've dropped automatic load of the dsdt table on the piix for now. We can't pull this in until we have snapshot of the dsdt aml, and I wanted it to be done at a clean seabios freeze point (Although I guess that could be the current snapshot). I don't see the harm in pulling this in later though. I've also gone to a model of the pci host being sparse: 00:00.0 Host bridge: Intel Corporation 82G33/G31/P35/P31 Express DRAM Controller 00:01.0 VGA compatible controller: Cirrus Logic GD 5446 00:02.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Controller (rev 03) 00:1f.0 ISA bridge: Intel Corporation 82801IB (ICH9) LPC Interface Controller (rev 02) 00:1f.2 SATA controller: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port SATA AHCI Controller (rev 02) 00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 02) The idea is only to populate the essential stuff at 1f, and have the rest filled out via command line options. In this way we have minimal bus configuration with 1 slot occupied as in piix. Should make things easier for libvirt. And this way user has complete control over things. For example, I have added support that when '-usb' is passed the usb controllers for ich9 are filled out. Todo: -add ahci migration back (need to cover more fields, but basically works) -add base addr for hpet in LPC device (for osx per agraf) -convert hotplug to use MemoryRegionPortio for hotplug (need an IsaDevice?) - add acpi hotplug for devices behind bridge (this is needed so we can add e.g. PCI devices behind a bridge in a compliant way) Thanks, -Jason Changes from v2: -Patch restructure (broke out ich9 chips + data structures separately) -added passthrough support -add support for -usb to fill out host pci bus -Dropped automatic load of dsdt table for piix -cleanups -dropped wmask on smbus (mst) -sparse host bus Changes from v1: -Updated end of low mem from 0xe000 - 0xb000 (Gerd Hoffmann) -so 0xb00-0xc00 is memconfig -0xc00-0xfec0 is 32-bit pci window -style/various cleanups -introduced IF_AHCI -introduced mach_if -split dsdt out of bios, now passed for piix4 as well (Paolo, Gerd) -Removed add opaque argument to pci_map_irq_fn (Michael S. Tsirkin) -removed patches that were merged in v1 Isaku Yamahata (6): pci: pci capability must be in PCI space pci: introduce pci_swizzle_map_irq_fn() for standardized interrupt pin swizzle pc, pc_piix: split out pc nic initialization pc/piix_pci: factor out smram/pam logic pci_ids: add intel 82801BA pci-to-pci bridge id q35: Introduce q35 pc based chipset emulator Jan Kiszka (5): pci: Add class 0xc05 as 'SMBus' q35: Suppress SMM BIOS initialization under KVM q35: Fix non-PCI IRQ processing in ich9_lpc_update_apic q35: smbus: Remove PCI_STATUS_SIG_SYSTEM_ERROR and PCI_STATUS_DETECTED_PARITY from w1cmask q35: Add kvmclock support Jason Baron (15): blockdev: Introduce a default machine blockdev interface field, QEMUMachine-mach_if blockdev: Introduce IF_AHCI pc: Move ioapic_init() from pc_piix.c to pc.c pcie: pass pcie window size to pcie_host_mmcfg_update() pcie: Convert PCIExpressHost to use the QOM. ich9: Add acpi support and definitions ich9: Add the lpc chip ich9: Add smbus ich9: Add i82801b11 dmi-to-pci bridge Add i21154 bridge chip. Add a fallback bios file search, if -L fails. q35: automatically load the q35 dsdt table q35: add acpi-based pci hotplug. q35: fill in usb pci slots with -usb ich9: add support pci assignment blockdev.c| 17 ++- blockdev.h| 21 ++ hw/Makefile.objs |1 + hw/acpi_ich9.c| 492 +++ hw/acpi_ich9.h| 57 + hw/boards.h |2 +- hw/device-hotplug.c |
Re: [Qemu-devel] [PATCH v3 00/26] q35 qemu support
On Fri, Oct 19, 2012 at 04:43:25PM -0400, Jason Baron wrote: Hi, Qemu bits for q35 support, I'm posting the seabios changes separately. The patches require '-M pc_q35' and -L 'seabios dir with q35 changes' on the qemu command line. Hopefully, we can make it the default for x86 at some future point when we feel comfortable with it. The current patches have been tested with basic install testing and memory testing on f16, f17, windows 7 and windows 8. They can be run on the various BSD flavors by adding a 'piix4-ide' device to the pci bus. ie: -device piix4-ide. Patches have also been reported to work with a small dsdt change on OSX 10.6 as well. I've dropped the ahci migration bits, which means q35 is not migratable at the moment. I simply haven't had time to make them more complete yet. I'm hoping that we'll come to some agreement on the minimal functionality required for q35 to be merged. Git trees: git://github.com/jibaron/q35-qemu.git git://github.com/jibaron/q35-seabios.git Notes: I've dropped automatic load of the dsdt table on the piix for now. We can't pull this in until we have snapshot of the dsdt aml, and I wanted it to be done at a clean seabios freeze point (Although I guess that could be the current snapshot). I don't see the harm in pulling this in later though. I've also gone to a model of the pci host being sparse: 00:00.0 Host bridge: Intel Corporation 82G33/G31/P35/P31 Express DRAM Controller 00:01.0 VGA compatible controller: Cirrus Logic GD 5446 00:02.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Controller (rev 03) 00:1f.0 ISA bridge: Intel Corporation 82801IB (ICH9) LPC Interface Controller (rev 02) 00:1f.2 SATA controller: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port SATA AHCI Controller (rev 02) 00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 02) The idea is only to populate the essential stuff at 1f, and have the rest filled out via command line options. In this way we have minimal bus configuration with 1 slot occupied as in piix. Should make things easier for libvirt. And this way user has complete control over things. For example, I have added support that when '-usb' is passed the usb controllers for ich9 are filled out. Todo: -add ahci migration back (need to cover more fields, but basically works) -add base addr for hpet in LPC device (for osx per agraf) -convert hotplug to use MemoryRegionPortio for hotplug (need an IsaDevice?) Thanks, -Jason To me it looks like it's best to merge these bits so the patchset stops growing. However I'd like to make sure we don't create user confusion with all the missing bits. Would it make sense to temporarily rename the machine type e.g. pc-q35-experimental to stress it's not fully supported? -- MST
Re: [Qemu-devel] [PATCH v3 00/26] q35 qemu support
Hi, Would it make sense to temporarily rename the machine type e.g. pc-q35-experimental to stress it's not fully supported? I don't think this is needed as piix will continue to be the default. It will also cause trouble with libvirt when pc-q35-experimental goes away some day. cheers, Gerd
Re: [Qemu-devel] [PATCH v3 00/26] q35 qemu support
On 20.10.2012 00:43, Jason Baron wrote: Hi, Qemu bits for q35 support, I'm posting the seabios changes separately. The patches require '-M pc_q35' and -L 'seabios dir with q35 changes' on the Just a small maybe-nitpick: can we ue pc-q35 here instead of pc_q35 (ie, minus instead of underscore)? We've converted several underscores to minuses in a few places recently, in order to make it all consistent, maybe it is time to stop introducing new occurences? Note that other values for -machine already uses minus signs instead of underscores: pc-1.2, pc-0.15 etc... Thanks, /mjt
