aboutsummaryrefslogtreecommitdiff
path: root/hw/pci-host/q35.c
AgeCommit message (Collapse)AuthorFilesLines
11 daysq35: Remove unused mch_mcfg_baseDr. David Alan Gilbert1-10/+0
mch_mcfg_base has been unused since it was added by 6f1426ab0f ("ich9: APIs for pc guest info") back in 2013. Remove it. Signed-off-by: Dr. David Alan Gilbert <dave@treblig.org> Reviewed-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-09-13hw: Use device_class_set_legacy_reset() instead of opencodingPeter Maydell1-1/+1
Use device_class_set_legacy_reset() instead of opencoding an assignment to DeviceClass::reset. This change was produced with: spatch --macro-file scripts/cocci-macro-file.h \ --sp-file scripts/coccinelle/device-reset.cocci \ --keep-comments --smpl-spacing --in-place --dir hw Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20240830145812.1967042-8-peter.maydell@linaro.org
2024-04-23q35: Introduce smm_ranges property for q35-pci-hostIsaku Yamahata1-13/+29
Add a q35 property to check whether or not SMM ranges, e.g. SMRAM, TSEG, etc... exist for the target platform. TDX doesn't support SMM and doesn't play nice with QEMU modifying related guest memory ranges. Signed-off-by: Isaku Yamahata <isaku.yamahata@linux.intel.com> Co-developed-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com> Signed-off-by: Michael Roth <michael.roth@amd.com> Message-ID: <20240320083945.991426-19-michael.roth@amd.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2024-04-23pci-host/q35: Move PAM initialization above SMRAM initializationIsaku Yamahata1-9/+10
In mch_realize(), process PAM initialization before SMRAM initialization so that later patch can skill all the SMRAM related with a single check. Signed-off-by: Isaku Yamahata <isaku.yamahata@intel.com> Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com> Signed-off-by: Michael Roth <michael.roth@amd.com> Message-ID: <20240320083945.991426-18-michael.roth@amd.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-12-30hw/pci-host: Constify VMStateRichard Henderson1-1/+1
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20231221031652.119827-47-richard.henderson@linaro.org>
2023-09-29pc: remove short_root_bus propertyPaolo Bonzini1-7/+0
The property was only used on QEMU 1.6 machine types. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-07-10hw/pci-host/q35: Make some property name macros reusable by i440fxBernhard Beschow1-4/+4
Signed-off-by: Bernhard Beschow <shentey@gmail.com> Message-Id: <20230630073720.21297-7-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-07-10hw/pci-host/q35: Initialize PCI_HOST_BYPASS_IOMMU property from board codeBernhard Beschow1-2/+1
The Q35 PCI host already has a PCI_HOST_BYPASS_IOMMU property. However, the host initializes this property itself by accessing global machine state, thereby assuming it to be a PC machine. Avoid this by having board code set this property. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230630073720.21297-6-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-07-10hw/pci-host/q35: Initialize PCMachineState::bus in board codeBernhard Beschow1-1/+0
The Q35 PCI host currently sets the PC machine's PCI bus attribute through global state, thereby assuming the machine to be a PC machine. The Q35 machine code already holds on to Q35's pci bus attribute, so can easily set its own property while preserving encapsulation. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230630073720.21297-4-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-07-10hw/pci-host/q35: Fix double, contradicting .endianness assignmentBernhard Beschow1-1/+0
Fixes the following clangd warning (-Winitializer-overrides): q35.c:297:19: Initializer overrides prior initialization of this subobject q35.c:292:19: previous initialization is here Settle on little endian which is consistent with using pci_host_conf_le_ops. Fixes: bafc90bdc594 ("q35: implement TSEG") Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230630073720.21297-3-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-05-19hw/pci-host/pam: Make init_pam() usage more readableBernhard Beschow1-4/+4
Unlike pam_update() which takes the subject -- PAMMemoryRegion -- as first argument, init_pam() takes it as fifth (!) argument. This makes it quite hard to figure out what an init_pam() invocation actually initializes. By moving the subject to the front this should become clearer. While at it, lower the DeviceState parameter to Object, also communicating more clearly that this parameter is just the owner rather than some (heavy?) dependency. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230213162004.2797-8-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-05-19hw/pci-host/q35: Inline sysbus_add_io()Bernhard Beschow1-2/+4
sysbus_add_io() just wraps memory_region_add_subregion() while also obscuring where the memory is attached. So use memory_region_add_subregion() directly and attach it to the existing memory region s->mch.address_space_io which is set as an alias to get_system_io() by the q35 machine. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20230213162004.2797-3-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-01-16hw/i386/pc: Remove unused 'owner' argument from pc_pci_as_mapping_initPhilippe Mathieu-Daudé1-2/+1
This argument was added 9 years ago in commit 83d08f2673 ("pc: map PCI address space as catchall region for not mapped addresses") and has never been used since, so remove it. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Bernhard Beschow <shentey@gmail.com> Message-Id: <20230105173826.56748-1-philmd@linaro.org> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2022-06-15q35：Enable TSEG only when G_SMRAME and TSEG_EN both enabledZhenzhong Duan1-1/+2
According to spec: "TSEG Enable (T_EN): Enabling of SMRAM memory for Extended SMRAM space only. When G_SMRAME = 1 and TSEG_EN = 1, the TSEG is enabled to appear in the appropriate physical address space. Note that once D_LCK is set, this bit becomes read only." Changed to match the spec description. Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Message-Id: <20220615034501.2733802-1-zhenzhong.duan@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-07-16hw/i386: Add a default_bus_bypass_iommu pc machine optionXingang Wang1-0/+2
Add a default_bus_bypass_iommu pc machine option to enable/disable bypass_iommu for default root bus. The option is disabled by default and can be enabled with: $QEMU -machine q35,default_bus_bypass_iommu=true Signed-off-by: Xingang Wang <wangxingang5@huawei.com> Message-Id: <1625748919-52456-5-git-send-email-wangxingang5@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-07-03hw/pci-host/q35: Ignore write of reserved PCIEXBAR LENGTH fieldPhilippe Mathieu-Daudé1-0/+3
libFuzzer triggered the following assertion: cat << EOF | qemu-system-i386 -M pc-q35-5.0 \ -nographic -monitor none -serial none \ -qtest stdio -d guest_errors -trace pci\* outl 0xcf8 0xf2000060 outl 0xcfc 0x8400056e EOF pci_cfg_write mch 00:0 @0x60 <- 0x8400056e Aborted (core dumped) This is because guest wrote MCH_HOST_BRIDGE_PCIEXBAR_LENGTH_RVD (reserved value) to the PCIE XBAR register. There is no indication on the datasheet about what occurs when this value is written. Simply ignore it on QEMU (and report an guest error): pci_cfg_write mch 00:0 @0x60 <- 0x8400056e Q35: Reserved PCIEXBAR LENGTH pci_cfg_read mch 00:0 @0x0 -> 0x8086 pci_cfg_read mch 00:0 @0x0 -> 0x29c08086 ... Cc: qemu-stable@nongnu.org Reported-by: Alexander Bulekov <alxndr@bu.edu> BugLink: https://bugs.launchpad.net/qemu/+bug/1878641 Fixes: df2d8b3ed4 ("q35: Introduce q35 pc based chipset emulator") Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20210526142438.281477-1-f4bug@amsat.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Alexander Bulekov <alxndr@bu.edu> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-12-13hw/pci-host/pam: Replace magic number by PAM_REGIONS_COUNT definitionPhilippe Mathieu-Daudé1-1/+1
While this change helps triskaidekaphobic developers, it is a good practice to avoid magic values and using constant definitions instead. Introduce the PAM_REGIONS_COUNT and use it. No logical change. Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Julia Suvorova <jusual@redhat.com> Message-Id: <20201202132038.1276404-1-philmd@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2020-06-15qom: Less verbose object_initialize_child()Markus Armbruster1-2/+1
All users of object_initialize_child() pass the obvious child size argument. Almost all pass &error_abort and no properties. Tiresome. Rename object_initialize_child() to object_initialize_child_with_props() to free the name. New convenience wrapper object_initialize_child() automates the size argument, and passes &error_abort and no properties. Rename object_initialize_childv() to object_initialize_child_with_propsv() for consistency. Convert callers with this Coccinelle script: @@ expression parent, propname, type; expression child, size; symbol error_abort; @@ - object_initialize_child(parent, propname, OBJECT(child), size, type, &error_abort, NULL) + object_initialize_child(parent, propname, child, size, type, &error_abort, NULL) @@ expression parent, propname, type; expression child; symbol error_abort; @@ - object_initialize_child(parent, propname, child, sizeof(*child), type, &error_abort, NULL) + object_initialize_child(parent, propname, child, type) @@ expression parent, propname, type; expression child; symbol error_abort; @@ - object_initialize_child(parent, propname, &child, sizeof(child), type, &error_abort, NULL) + object_initialize_child(parent, propname, &child, type) @@ expression parent, propname, type; expression child, size, err; expression list props; @@ - object_initialize_child(parent, propname, child, size, type, err, props) + object_initialize_child_with_props(parent, propname, child, size, type, err, props) Note that Coccinelle chokes on ARMSSE typedef vs. macro in hw/arm/armsse.c. Worked around by temporarily renaming the macro for the spatch run. Signed-off-by: Markus Armbruster <armbru@redhat.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> [Rebased: machine opentitan is new (commit fe0fe4735e7)] Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20200610053247.1583243-37-armbru@redhat.com>
2020-06-15qdev: Convert uses of qdev_set_parent_bus() with CoccinelleMarkus Armbruster1-2/+1
In addition to the qdev_create() patterns converted so far, we have a qdev_set_parent_bus() pattern. Mostly when we embed a device in a parent device rather than allocating it on the heap. This pattern also puts devices in the dangerous "no QOM parent, but plugged into bus" state I explained in recent commit "qdev: New qdev_new(), qdev_realize(), etc." Apply same solution: convert to qdev_realize(). Coccinelle script: @@ expression dev, bus, errp; symbol true; @@ - qdev_set_parent_bus(DEVICE(dev), bus); ... - object_property_set_bool(OBJECT(dev), true, "realized", errp); + qdev_realize(DEVICE(dev), bus, errp); @ depends on !(file in "qdev-monitor.c") && !(file in "hw/core/qdev.c")@ expression dev, bus, errp; symbol true; @@ - qdev_set_parent_bus(dev, bus); ... - object_property_set_bool(OBJECT(dev), true, "realized", errp); + qdev_realize(dev, bus, errp); @@ expression dev, bus; symbol true; @@ - qdev_set_parent_bus(DEVICE(dev), bus); ... - qdev_init_nofail(DEVICE(dev)); + qdev_realize(DEVICE(dev), bus, &error_fatal); Unconverted uses of qdev_set_parent_bus() remain. They'll be converted later in this series. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20200610053247.1583243-12-armbru@redhat.com> [Also convert new hw/virtio/vhost-user-vsock-pci.c]
2020-06-09hw/pci-host: Use the IEC binary prefix definitionsPhilippe Mathieu-Daudé1-1/+1
IEC binary prefixes ease code review: the unit is explicit. Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20200601142930.29408-6-f4bug@amsat.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
2020-05-15qom: Drop parameter @errp of object_property_add() & friendsMarkus Armbruster1-10/+10
The only way object_property_add() can fail is when a property with the same name already exists. Since our property names are all hardcoded, failure is a programming error, and the appropriate way to handle it is passing &error_abort. Same for its variants, except for object_property_add_child(), which additionally fails when the child already has a parent. Parentage is also under program control, so this is a programming error, too. We have a bit over 500 callers. Almost half of them pass &error_abort, slightly fewer ignore errors, one test case handles errors, and the remaining few callers pass them to their own callers. The previous few commits demonstrated once again that ignoring programming errors is a bad idea. Of the few ones that pass on errors, several violate the Error API. The Error ** argument must be NULL, &error_abort, &error_fatal, or a pointer to a variable containing NULL. Passing an argument of the latter kind twice without clearing it in between is wrong: if the first call sets an error, it no longer points to NULL for the second call. ich9_pm_add_properties(), sparc32_ledma_realize(), sparc32_dma_realize(), xilinx_axidma_realize(), xilinx_enet_realize() are wrong that way. When the one appropriate choice of argument is &error_abort, letting users pick the argument is a bad idea. Drop parameter @errp and assert the preconditions instead. There's one exception to "duplicate property name is a programming error": the way object_property_add() implements the magic (and undocumented) "automatic arrayification". Don't drop @errp there. Instead, rename object_property_add() to object_property_try_add(), and add the obvious wrapper object_property_add(). Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20200505152926.18877-15-armbru@redhat.com> [Two semantic rebase conflicts resolved]
2020-03-16qom/object: Use common get/set uint helpersFelipe Franciosi1-11/+3
Several objects implemented their own uint property getters and setters, despite them being straightforward (without any checks/validations on the values themselves) and identical across objects. This makes use of an enhanced API for object_property_add_uintXX_ptr() which offers default setters. Some of these setters used to update the value even if the type visit failed (eg. because the value being set overflowed over the given type). The new setter introduces a check for these errors, not updating the value if an error occurred. The error is propagated. Signed-off-by: Felipe Franciosi <felipe@nutanix.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-09hw/pci-host/q35: Remove unused includesPhilippe Mathieu-Daudé1-0/+1
Only q35.c requires declarations from "hw/i386/pc.h", move it there. Remove all the includes not used by "q35.h". Acked-by: John Snow <jsnow@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20200228114649.12818-18-philmd@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2020-01-27Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into stagingPeter Maydell1-2/+2
* Register qdev properties as class properties (Marc-André) * Cleanups (Philippe) * virtio-scsi fix (Pan Nengyuan) * Tweak Skylake-v3 model id (Kashyap) * x86 UCODE_REV support and nested live migration fix (myself) * Advisory mode for pvpanic (Zhenwei) # gpg: Signature made Fri 24 Jan 2020 20:16:23 GMT # gpg: using RSA key BFFBD25F78C7AE83 # gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>" [full] # gpg: aka "Paolo Bonzini <pbonzini@redhat.com>" [full] # Primary key fingerprint: 46F5 9FBD 57D6 12E7 BFD4 E2F7 7E15 100C CD36 69B1 # Subkey fingerprint: F133 3857 4B66 2389 866C 7682 BFFB D25F 78C7 AE83 * remotes/bonzini/tags/for-upstream: (58 commits) build-sys: clean up flags included in the linker command line target/i386: Add the 'model-id' for Skylake -v3 CPU models qdev: use object_property_help() qapi/qmp: add ObjectPropertyInfo.default-value qom: introduce object_property_help() qom: simplify qmp_device_list_properties() vl: print default value in object help qdev: register properties as class properties qdev: move instance properties to class properties qdev: rename DeviceClass.props qdev: set properties with device_class_set_props() object: return self in object_ref() object: release all props object: add object_class_property_add_link() object: express const link with link property object: add direct link flag object: rename link "child" to "target" object: check strong flag with & object: do not free class properties object: add object_property_set_default ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-01-24qdev: set properties with device_class_set_props()Marc-André Lureau1-2/+2
The following patch will need to handle properties registration during class_init time. Let's use a device_class_set_props() setter. spatch --macro-file scripts/cocci-macro-file.h --sp-file ./scripts/coccinelle/qdev-set-props.cocci --keep-comments --in-place --dir . @@ typedef DeviceClass; DeviceClass *d; expression val; @@ - d->props = val + device_class_set_props(d, val) Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20200110153039.1379601-20-marcandre.lureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-01-22q35: implement 128K SMRAM at default SMBASE addressIgor Mammedov1-7/+77
It's not what real HW does, implementing which would be overkill [**] and would require complex cross stack changes (QEMU+firmware) to make it work. So considering that SMRAM is owned by MCH, for simplicity (ab)use reserved Q35 register, which allows QEMU and firmware easily init and make RAM at SMBASE available only from SMM context. Patch uses commit (2f295167e0 q35/mch: implement extended TSEG sizes) for inspiration and uses reserved register in config space at 0x9c offset [*] to extend q35 pci-host with ability to use 128K at 0x30000 as SMRAM and hide it (like TSEG) from non-SMM context. Usage: 1: write 0xff in the register 2: if the feature is supported, follow up read from the register should return 0x01. At this point RAM at 0x30000 is still available for SMI handler configuration from non-SMM context 3: writing 0x02 in the register, locks SMBASE area, making its contents available only from SMM context. In non-SMM context, reads return 0xff and writes are ignored. Further writes into the register are ignored until the system reset. *) https://www.mail-archive.com/qemu-devel@nongnu.org/msg455991.html **) https://www.mail-archive.com/qemu-devel@nongnu.org/msg646965.html Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <1575896942-331151-3-git-send-email-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com>
2019-08-16Include hw/qdev-properties.h lessMarkus Armbruster1-0/+1
In my "build everything" tree, changing hw/qdev-properties.h triggers a recompile of some 2700 out of 6600 objects (not counting tests and objects that don't depend on qemu/osdep.h). Many places including hw/qdev-properties.h (directly or via hw/qdev.h) actually need only hw/qdev-core.h. Include hw/qdev-core.h there instead. hw/qdev.h is actually pointless: all it does is include hw/qdev-core.h and hw/qdev-properties.h, which in turn includes hw/qdev-core.h. Replace the remaining uses of hw/qdev.h by hw/qdev-properties.h. While there, delete a few superfluous inclusions of hw/qdev-core.h. Touching hw/qdev-properties.h now recompiles some 1200 objects. Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: "Daniel P. Berrangé" <berrange@redhat.com> Cc: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20190812052359.30071-22-armbru@redhat.com>
2019-08-16Include hw/hw.h exactly where neededMarkus Armbruster1-1/+0
In my "build everything" tree, changing hw/hw.h triggers a recompile of some 2600 out of 6600 objects (not counting tests and objects that don't depend on qemu/osdep.h). The previous commits have left only the declaration of hw_error() in hw/hw.h. This permits dropping most of its inclusions. Touching it now recompiles less than 200 objects. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20190812052359.30071-19-armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2019-08-16Include migration/vmstate.h lessMarkus Armbruster1-0/+1
In my "build everything" tree, changing migration/vmstate.h triggers a recompile of some 2700 out of 6600 objects (not counting tests and objects that don't depend on qemu/osdep.h). hw/hw.h supposedly includes it for convenience. Several other headers include it just to get VMStateDescription. The previous commit made that unnecessary. Include migration/vmstate.h only where it's still needed. Touching it now recompiles only some 1600 objects. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20190812052359.30071-16-armbru@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2019-06-16q35: fix mmconfig and PCI0._CRSGerd Hoffmann1-23/+8
This patch changes the handling of the mmconfig area. Thanks to the pci(e) expander devices we already have the logic to exclude address ranges from PCI0._CRS. We can simply add the mmconfig address range to the list get it excluded as well. With that in place we can go with a fixed pci hole which covers the whole area from the end of (low) ram to the ioapic. This will make the whole logic alot less fragile. No matter where the firmware places the mmconfig xbar, things should work correctly. The guest also gets a bit more PCI address space (seabios boot): # cat /proc/iomem [ ... ] 7ffdd000-7fffffff : reserved 80000000-afffffff : PCI Bus 0000:00 <<-- this is new b0000000-bfffffff : PCI MMCONFIG 0000 [bus 00-ff] b0000000-bfffffff : reserved c0000000-febfffff : PCI Bus 0000:00 f8000000-fbffffff : 0000:00:01.0 [ ... ] So this is a guest visible change. Cc: László Érsek <lersek@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20190607073429.3436-1-kraxel@redhat.com>
2019-06-12Include qemu/module.h where needed, drop it from qemu-common.hMarkus Armbruster1-0/+2
Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20190523143508.25387-4-armbru@redhat.com> [Rebased with conflicts resolved automatically, except for hw/usb/dev-hub.c hw/misc/exynos4210_rng.c hw/misc/bcm2835_rng.c hw/misc/aspeed_scu.c hw/display/virtio-vga.c hw/arm/stm32f205_soc.c; ui/cocoa.m fixed up]
2019-05-02hw/pci-host: Use object_initialize_child for correct reference countingThomas Huth1-2/+2
Both functions, object_initialize() and object_property_add_child() increase the reference counter of the new object, so one of the references has to be dropped afterwards to get the reference counting right. Otherwise the child object might not be properly cleaned up when the parent gets destroyed. Some functions of the pci-host devices miss to drop one of the references. Fix it by using object_initialize_child() instead, which takes care of calling object_initialize(), object_property_add_child() and object_unref() in the right order. Suggested-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20190430191552.4027-1-thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2018-11-08Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into stagingPeter Maydell1-1/+9
* icount fix (Clement) * dumping fixes for non-volatile memory (Marc-André, myself) * x86 emulation fix (Rudolf) * recent Hyper-V CPUID flag (Vitaly) * Q35 doc fix (Daniel) * lsi fix (Prasad) * SCSI block limits emulation fixes (myself) * qemu_thread_atexit rework (Peter) * ivshmem memory leak fix (Igor) # gpg: Signature made Tue 06 Nov 2018 21:34:30 GMT # gpg: using RSA key BFFBD25F78C7AE83 # gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>" # gpg: aka "Paolo Bonzini <pbonzini@redhat.com>" # Primary key fingerprint: 46F5 9FBD 57D6 12E7 BFD4 E2F7 7E15 100C CD36 69B1 # Subkey fingerprint: F133 3857 4B66 2389 866C 7682 BFFB D25F 78C7 AE83 * remotes/bonzini/tags/for-upstream: util/qemu-thread-posix: Fix qemu_thread_atexit* for OSX include/qemu/thread.h: Document qemu_thread_atexit* API scsi-generic: do not do VPD emulation for sense other than ILLEGAL_REQUEST scsi-generic: avoid invalid access to struct when emulating block limits scsi-generic: avoid out-of-bounds access to VPD page list scsi-generic: keep VPD page list sorted lsi53c895a: check message length value is valid scripts/dump-guest-memory: Synchronize with guest_phys_blocks_region_add memory-mapping: skip non-volatile memory regions in GuestPhysBlockList nvdimm: set non-volatile on the memory region memory: learn about non-volatile memory region target/i386: Clear RF on SYSCALL instruction MAINTAINERS: remove or downgrade myself to reviewer from some subsystems ivshmem: fix memory backend leak i386: clarify that the Q35 machine type implements a P35 chipset x86: hv_evmcs CPU flag support icount: fix deadlock when all cpus are sleeping Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2018-11-06i386: clarify that the Q35 machine type implements a P35 chipsetDaniel P. Berrangé1-1/+9
The 'q35' machine type implements an Intel Series 3 chipset, of which there are several variants: https://www.intel.com/Assets/PDF/datasheet/316966.pdf The key difference between the 82P35 MCH ('p35', PCI device ID 0x29c0) and 82Q35 GMCH ('q35', PCI device ID 0x29b0) variants is that the latter has an integrated graphics adapter. QEMU does not implement integrated graphics, so uses the PCI ID for the 82P35 chipset, despite calling the machine type 'q35'. Thus we rename the PCI device ID constant to reflect reality, to avoid confusing future developers. The new name more closely matches what pci.ids reports it to be: $ grep P35 /usr/share/hwdata/pci.ids | grep 29 29c0 82G33/G31/P35/P31 Express DRAM Controller 29c1 82G33/G31/P35/P31 Express PCI Express Root Port 29c4 82G33/G31/P35/P31 Express MEI Controller 29c5 82G33/G31/P35/P31 Express MEI Controller 29c6 82G33/G31/P35/P31 Express PT IDER Controller 29c7 82G33/G31/P35/P31 Express Serial KT Controller $ grep Q35 /usr/share/hwdata/pci.ids | grep 29 29b0 82Q35 Express DRAM Controller 29b1 82Q35 Express PCI Express Root Port 29b2 82Q35 Express Integrated Graphics Controller 29b3 82Q35 Express Integrated Graphics Controller 29b4 82Q35 Express MEI Controller 29b5 82Q35 Express MEI Controller 29b6 82Q35 Express PT IDER Controller 29b7 82Q35 Express Serial KT Controller Arguably the QEMU machine type should be named 'p35'. At this point in time, however, it is not worth the churn for management applications & documentation to worry about renaming it. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20180830105757.10577-1-berrange@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-11-05hw/pci-host/x86: extend the 64-bit PCI hole relative to the fw-assigned baseLaszlo Ersek1-1/+1
In commit 9fa99d2519cb ("hw/pci-host: Fix x86 Host Bridges 64bit PCI hole", 2017-11-16), we meant to expose such a 64-bit PCI MMIO aperture in the ACPI DSDT that would be at least as large as the new "pci-hole64-size" property (2GB on i440fx, 32GB on q35). The goal was to offer "enough" 64-bit MMIO aperture to the guest OS for hotplug purposes. In that commit, we added or modified five functions: - pc_pci_hole64_start(): shared between i440fx and q35. Provides a default 64-bit base, which starts beyond the cold-plugged 64-bit RAM, and skips the DIMM hotplug area too (if any). - i440fx_pcihost_get_pci_hole64_start(), q35_host_get_pci_hole64_start(): board-specific 64-bit base property getters called abstractly by the ACPI generator. Both of these fall back to pc_pci_hole64_start() if the firmware didn't program any 64-bit hole (i.e. if the firmware didn't assign a 64-bit GPA to any MMIO BAR on any device). Otherwise, they honor the firmware's BAR assignments (i.e., they treat the lowest 64-bit GPA programmed by the firmware as the base address for the aperture). - i440fx_pcihost_get_pci_hole64_end(), q35_host_get_pci_hole64_end(): these intended to extend the aperture to our size recommendation, calculated relative to the base of the aperture. Despite the original intent, i440fx_pcihost_get_pci_hole64_end() and q35_host_get_pci_hole64_end() currently only extend the aperture relative to the default base (pc_pci_hole64_start()), ignoring any programming done by the firmware. This means that our size recommendation may not be met. Fix it by honoring the firmware's address assignments. The strange extension sizes were spotted by Alex, in the log of a guest kernel running on top of OVMF (which prefers to assign 64-bit GPAs to 64-bit BARs). This change only affects DSDT generation, therefore no new compat property is being introduced. Using an i440fx OVMF guest with 5GB RAM, an example _CRS change is: > @@ -881,9 +881,9 @@ > QWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, > 0x0000000000000000, // Granularity > 0x0000000800000000, // Range Minimum > - 0x000000080001C0FF, // Range Maximum > + 0x000000087FFFFFFF, // Range Maximum > 0x0000000000000000, // Translation Offset > - 0x000000000001C100, // Length > + 0x0000000080000000, // Length > ,, , AddressRangeMemory, TypeStatic) > }) > Device (GPE0) (On i440fx, the low RAM split is at 3GB, in this case. Therefore, with 5GB guest RAM and no DIMM hotplug range, pc_pci_hole64_start() returns 4 + (5-3) = 6 GB. Adding the 2GB extension to that yields 8GB, which is below the firmware-programmed base of 32GB, before the patch. Therefore, before the patch, the extension is ineffective. After the patch, we add the 2GB extension to the firmware-programmed base, namely 32GB.) Using a q35 OVMF guest with 5GB RAM, an example _CRS change is: > @@ -3162,9 +3162,9 @@ > QWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, > 0x0000000000000000, // Granularity > 0x0000000800000000, // Range Minimum > - 0x00000009BFFFFFFF, // Range Maximum > + 0x0000000FFFFFFFFF, // Range Maximum > 0x0000000000000000, // Translation Offset > - 0x00000001C0000000, // Length > + 0x0000000800000000, // Length > ,, , AddressRangeMemory, TypeStatic) > }) > Device (GPE0) (On Q35, the low RAM split is at 2GB. Therefore, with 5GB guest RAM and no DIMM hotplug range, pc_pci_hole64_start() returns 4 + (5-2) = 7 GB. Adding the 32GB extension to that yields 39GB (0x0000_0009_BFFF_FFFF + 1), before the patch. After the patch, we add the 32GB extension to the firmware-programmed base, namely 32GB.) The ACPI test data for the bios-tables-test case that we added earlier in this series are corrected too, as follows: > @@ -3339,9 +3339,9 @@ > QWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, > 0x0000000000000000, // Granularity > 0x0000000200000000, // Range Minimum > - 0x00000009BFFFFFFF, // Range Maximum > + 0x00000009FFFFFFFF, // Range Maximum > 0x0000000000000000, // Translation Offset > - 0x00000007C0000000, // Length > + 0x0000000800000000, // Length > ,, , AddressRangeMemory, TypeStatic) > }) > Device (GPE0) Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Alex Williamson <alex.williamson@redhat.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Marcel Apfelbaum <marcel.apfelbaum@gmail.com> Fixes: 9fa99d2519cbf71f871e46871df12cb446dc1c3e Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2018-11-05hw/pci-host/x86: extract get_pci_hole64_start_value() helpersLaszlo Ersek1-4/+11
Expose the calculated "hole64 start" GPAs as plain uint64_t values, extracting the internals of the current property getters. This patch doesn't change behavior. Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Alex Williamson <alex.williamson@redhat.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Marcel Apfelbaum <marcel.apfelbaum@gmail.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2018-10-26hw/pci-host: Remove useless parenthesis around DIV_ROUND_UP macroPhilippe Mathieu-Daudé1-1/+1
Patch created mechanically by rerunning: $ spatch --sp-file scripts/coccinelle/round.cocci \ --macro-file scripts/cocci-macro-file.h \ --dir . --in-place Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Markus Armbruster <armbru@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Message-Id: <20180705155811.20366-7-f4bug@amsat.org> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2018-10-19target-i386: add q35 0xcf8 port as coalesced_pioPeng Hao1-0/+4
Signed-off-by: Peng Hao <peng.hao2@zte.com.cn> Message-Id: <1539795177-21038-6-git-send-email-peng.hao2@zte.com.cn> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-05-23hw/pci-host/q35: Replace hardcoded value with macroZihan Yang1-6/+11
During smram region initialization some addresses are hardcoded, replace them with macro to be more clear to readers. Previous patch forgets about one value and exceeds the line limit of 90 characters. The v2 breaks a few long lines Signed-off-by: Zihan Yang <whois.zihan.yang@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-12-05pci: Rename root bus initialization functions for clarityDavid Gibson1-3/+4
pci_bus_init(), pci_bus_new_inplace(), pci_bus_new() and pci_register_bus() are misleadingly named. They're not used for initializing *any* PCI bus, but only for a root PCI bus. Non-root buses - i.e. ones under a logical PCI to PCI bridge - are instead created with a direct qbus_create_inplace() (see pci_bridge_initfn()). This patch renames the functions to make it clear they're only used for a root bus. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Marcel Apfelbaum <marcel@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com>
2017-11-16hw/pci-host: Fix x86 Host Bridges 64bit PCI holeMarcel Apfelbaum1-3/+39
Currently there is no MMIO range over 4G reserved for PCI hotplug. Since the 32bit PCI hole depends on the number of cold-plugged PCI devices and other factors, it is very possible is too small to hotplug PCI devices with large BARs. Fix it by reserving 2G for I4400FX chipset in order to comply with older Win32 Guest OSes and 32G for Q35 chipset. Even if the new defaults of pci-hole64-size will appear in "info qtree" also for older machines, the property was not implemented so no changes will be visible to guests. Note this is a regression since prev QEMU versions had some range reserved for 64bit PCI hotplug. Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Marcel Apfelbaum <marcel@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-10-15pci: Add INTERFACE_CONVENTIONAL_PCI_DEVICE to Conventional PCI devicesEduardo Habkost1-0/+4
Add INTERFACE_CONVENTIONAL_PCI_DEVICE to all direct subtypes of TYPE_PCI_DEVICE, except: 1) The ones that already have INTERFACE_PCIE_DEVICE set: * base-xhci * e1000e * nvme * pvscsi * vfio-pci * virtio-pci * vmxnet3 2) base-pci-bridge Not all PCI bridges are Conventional PCI devices, so INTERFACE_CONVENTIONAL_PCI_DEVICE is added only to the subtypes that are actually Conventional PCI: * dec-21154-p2p-bridge * i82801b11-bridge * pbm-bridge * pci-bridge The direct subtypes of base-pci-bridge not touched by this patch are: * xilinx-pcie-root: Already marked as PCIe-only. * pcie-pci-bridge: Already marked as PCIe-only. * pcie-port: all non-abstract subtypes of pcie-port are already marked as PCIe-only devices. 3) megasas-base Not all megasas devices are Conventional PCI devices, so the interface names are added to the subclasses registered by megasas_register_types(), according to information in the megasas_devices[] array. "megasas-gen2" already implements INTERFACE_PCIE_DEVICE, so add INTERFACE_CONVENTIONAL_PCI_DEVICE only to "megasas". Acked-by: Alberto Garcia <berto@igalia.com> Acked-by: John Snow <jsnow@redhat.com> Acked-by: Anthony PERARD <anthony.perard@citrix.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Acked-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Marcel Apfelbaum <marcel@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-08-31q35: use DIV_ROUND_UPMarc-André Lureau1-1/+1
I used the clang-tidy qemu-round check to generate the fix: https://github.com/elmarco/clang-tools-extra Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Richard Henderson <rth@twiddle.net>
2017-06-22Merge remote-tracking branch 'remotes/armbru/tags/pull-qapi-2017-06-09-v2' ↵Peter Maydell1-8/+7
into staging QAPI patches for 2017-06-09 # gpg: Signature made Tue 20 Jun 2017 13:31:39 BST # gpg: using RSA key 0x3870B400EB918653 # gpg: Good signature from "Markus Armbruster <armbru@redhat.com>" # gpg: aka "Markus Armbruster <armbru@pond.sub.org>" # Primary key fingerprint: 354B C8B3 D7EB 2A6B 6867 4E5F 3870 B400 EB91 8653 * remotes/armbru/tags/pull-qapi-2017-06-09-v2: (41 commits) tests/qdict: check more get_try_int() cases console: use get_uint() for "head" property i386/cpu: use get_uint() for "min-level"/"min-xlevel" properties numa: use get_uint() for "size" property pnv-core: use get_uint() for "core-pir" property pvpanic: use get_uint() for "ioport" property auxbus: use get_uint() for "addr" property arm: use get_uint() for "mp-affinity" property xen: use get_uint() for "max-ram-below-4g" property pc: use get_uint() for "hpet-intcap" property pc: use get_uint() for "apic-id" property pc: use get_uint() for "iobase" property acpi: use get_uint() for "pci-hole*" properties acpi: use get_uint() for various acpi properties acpi: use get_uint() for "acpi-pcihp-io*" properties platform-bus: use get_uint() for "addr" property bcm2835_fb: use {get, set}_uint() for "vcram-size" and "vcram-base" aspeed: use {set, get}_uint() for "ram-size" property pcihp: use get_uint() for "bsel" property pc-dimm: make "size" property uint64 ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2017-06-20qdev: Use appropriate getter/setters typeMarc-André Lureau1-1/+1
Based on the underlying type of the data accessed, use the appropriate getters/setters: * AcpiPmInfo members s3_disabled, s4_disabled are bool, member s4_val is an uint8_t * Property ACPI_PCIHP_IO_PROP is defined with object_property_add_uint32_ptr() * Property PCIE_HOST_MCFG_SIZE is implemented with visit_type_uint64() * PCIDevice property "addr" is backed by PCIDevice member devfn, which is an int32_t Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20170607163635.17635-20-marcandre.lureau@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> [More verbose commit message] Signed-off-by: Markus Armbruster <armbru@redhat.com>
2017-06-20object: use more specific property type namesMarc-André Lureau1-5/+5
Use the actual unsigned integer type name. The type name change impacts the following externally visible area: * vl.c's machine_help_func() puts it in help for -machine NAME,help. * QMP command qom-list exposes it in ObjectPropertyInfo member @type. * QMP command device-list-properties exposes it in DevicePropertyInfo member @type. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20170607163635.17635-15-marcandre.lureau@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2017-06-20q35: fix get_mmcfg_size to use uint64 visitorMarc-André Lureau1-2/+1
e->size is hwaddr, i.e. uint64_t. We silently truncate. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Suggested-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20170607163635.17635-14-marcandre.lureau@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2017-06-16q35/mch: implement extended TSEG sizesLaszlo Ersek1-3/+38
The q35 machine type currently lets the guest firmware select a 1MB, 2MB or 8MB TSEG (basically, SMRAM) size. In edk2/OVMF, we use 8MB, but even that is not enough when a lot of VCPUs (more than approx. 224) are configured -- SMRAM footprint scales largely proportionally with VCPU count. Introduce a new property for "mch" called "extended-tseg-mbytes", which expresses (in megabytes) the user's choice of TSEG (SMRAM) size. Invent a new, QEMU-specific register in the config space of the DRAM Controller, at offset 0x50, in order to allow guest firmware to query the TSEG (SMRAM) size. According to Intel Document Number 316966-002, Table 5-1 "DRAM Controller Register Address Map (D0:F0)": Warning: Address locations that are not listed are considered Intel Reserved registers locations. Reads to Reserved registers may return non-zero values. Writes to reserved locations may cause system failures. All registers that are defined in the PCI 2.3 specification, but are not necessary or implemented in this component are simply not included in this document. The reserved/unimplemented space in the PCI configuration header space is not documented as such in this summary. Offsets 0x50 and 0x51 are not listed in Table 5-1. They are also not part of the standard PCI config space header. And they precede the capability list as well, which starts at 0xe0 for this device. When the guest writes value 0xffff to this register, the value that can be read back is that of "mch.extended-tseg-mbytes" -- unless it remains 0xffff. The guest is required to write 0xffff first (as opposed to a read-only register) because PCI config space is generally not cleared on QEMU reset, and after S3 resume or reboot, new guest firmware running on old QEMU could read a guest OS-injected value from this register. After reading the available "extended" TSEG size, the guest firmware may actually request that TSEG size by writing pattern 11b to the ESMRAMC register's TSEG_SZ bit-field. (The Intel spec referenced above defines only patterns 00b (1MB), 01b (2MB) and 10b (8MB); 11b is reserved.) On the QEMU command line, the value can be set with -global mch.extended-tseg-mbytes=N The default value for 2.10+ q35 machine types is 16. The value is limited to 0xfff (4095) at the moment, purely so that the product (4095 MB) can be stored to the uint32_t variable "tseg_size" in mch_update_smram(). Users are responsible for choosing sensible TSEG sizes. On 2.9 and earlier q35 machine types, the default value is 0. This lets the 11b bit pattern in ESMRAMC.TSEG_SZ, and the register at offset 0x50, keep their original behavior. When "extended-tseg-mbytes" is nonzero, the new register at offset 0x50 is set to that value on reset, for completeness. PCI config space is migrated automatically, so no VMSD changes are necessary. Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1447027 Ref: https://lists.01.org/pipermail/edk2-devel/2017-May/010456.html Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-05-17qdev: Replace cannot_instantiate_with_device_add_yet with !user_creatableEduardo Habkost1-2/+2
cannot_instantiate_with_device_add_yet was introduced by commit efec3dd631d94160288392721a5f9c39e50fb2bc to replace no_user. It was supposed to be a temporary measure. When it was introduced, we had 54 cannot_instantiate_with_device_add_yet=true lines in the code. Today (3 years later) this number has not shrunk: we now have 57 cannot_instantiate_with_device_add_yet=true lines. I think it is safe to say it is not a temporary measure, and we won't see the flag go away soon. Instead of a long field name that misleads people to believe it is temporary, replace it a shorter and less misleading field: user_creatable. Except for code comments, changes were generated using the following Coccinelle patch: @@ expression DC; @@ ( -DC->cannot_instantiate_with_device_add_yet = false; +DC->user_creatable = true; | -DC->cannot_instantiate_with_device_add_yet = true; +DC->user_creatable = false; ) @@ typedef ObjectClass; expression dc; identifier class, data; @@ static void device_class_init(ObjectClass *class, void *data) { ... dc->hotpluggable = true; +dc->user_creatable = true; ... } @@ @@ struct DeviceClass { ... -bool cannot_instantiate_with_device_add_yet; +bool user_creatable; ... } @@ expression DC; @@ ( -!DC->cannot_instantiate_with_device_add_yet +DC->user_creatable | -DC->cannot_instantiate_with_device_add_yet +!DC->user_creatable ) Cc: Alistair Francis <alistair.francis@xilinx.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: Markus Armbruster <armbru@redhat.com> Cc: Peter Maydell <peter.maydell@linaro.org> Cc: Thomas Huth <thuth@redhat.com> Acked-by: Alistair Francis <alistair.francis@xilinx.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Marcel Apfelbaum <marcel@redhat.com> Acked-by: Marcel Apfelbaum <marcel@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20170503203604.31462-2-ehabkost@redhat.com> [ehabkost: kept "TODO remove once we're there" comment] Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-07-04range: Eliminate direct Range member accessMarkus Armbruster1-14/+27
Users of struct Range mess liberally with its members, which makes refactoring hard. Create a set of methods, and convert all users to call them instead of accessing members. The methods have carefully worded contracts, and use assertions to check them. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
generated by cgit v1.1 at 2024-10-14 06:44:30 +0000