2012-11-14 21:54:06 +01:00
|
|
|
/*
|
|
|
|
* QEMU MCH/ICH9 PCI Bridge Emulation
|
|
|
|
*
|
|
|
|
* Copyright (c) 2006 Fabrice Bellard
|
|
|
|
* Copyright (c) 2009, 2010, 2011
|
|
|
|
* Isaku Yamahata <yamahata at valinux co jp>
|
|
|
|
* VA Linux Systems Japan K.K.
|
|
|
|
* Copyright (C) 2012 Jason Baron <jbaron@redhat.com>
|
|
|
|
*
|
2014-08-11 10:10:25 +02:00
|
|
|
* This is based on piix.c, but heavily modified.
|
2012-11-14 21:54:06 +01:00
|
|
|
*
|
|
|
|
* Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
|
|
* of this software and associated documentation files (the "Software"), to deal
|
|
|
|
* in the Software without restriction, including without limitation the rights
|
|
|
|
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
|
|
* copies of the Software, and to permit persons to whom the Software is
|
|
|
|
* furnished to do so, subject to the following conditions:
|
|
|
|
*
|
|
|
|
* The above copyright notice and this permission notice shall be included in
|
|
|
|
* all copies or substantial portions of the Software.
|
|
|
|
*
|
|
|
|
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
|
|
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
|
|
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
|
|
|
|
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
|
|
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
|
|
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
|
|
|
|
* THE SOFTWARE.
|
|
|
|
*/
|
2019-05-23 16:35:07 +02:00
|
|
|
|
2016-01-26 19:17:03 +01:00
|
|
|
#include "qemu/osdep.h"
|
2021-05-26 16:24:38 +02:00
|
|
|
#include "qemu/log.h"
|
2020-02-28 12:46:48 +01:00
|
|
|
#include "hw/i386/pc.h"
|
2013-02-05 17:06:20 +01:00
|
|
|
#include "hw/pci-host/q35.h"
|
2019-08-12 07:23:51 +02:00
|
|
|
#include "hw/qdev-properties.h"
|
2019-08-12 07:23:45 +02:00
|
|
|
#include "migration/vmstate.h"
|
include/qemu/osdep.h: Don't include qapi/error.h
Commit 57cb38b included qapi/error.h into qemu/osdep.h to get the
Error typedef. Since then, we've moved to include qemu/osdep.h
everywhere. Its file comment explains: "To avoid getting into
possible circular include dependencies, this file should not include
any other QEMU headers, with the exceptions of config-host.h,
compiler.h, os-posix.h and os-win32.h, all of which are doing a
similar job to this file and are under similar constraints."
qapi/error.h doesn't do a similar job, and it doesn't adhere to
similar constraints: it includes qapi-types.h. That's in excess of
100KiB of crap most .c files don't actually need.
Add the typedef to qemu/typedefs.h, and include that instead of
qapi/error.h. Include qapi/error.h in .c files that need it and don't
get it now. Include qapi-types.h in qom/object.h for uint16List.
Update scripts/clean-includes accordingly. Update it further to match
reality: replace config.h by config-target.h, add sysemu/os-posix.h,
sysemu/os-win32.h. Update the list of includes in the qemu/osdep.h
comment quoted above similarly.
This reduces the number of objects depending on qapi/error.h from "all
of them" to less than a third. Unfortunately, the number depending on
qapi-types.h shrinks only a little. More work is needed for that one.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
[Fix compilation without the spice devel packages. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-03-14 09:01:28 +01:00
|
|
|
#include "qapi/error.h"
|
2013-07-29 16:47:57 +02:00
|
|
|
#include "qapi/visitor.h"
|
2019-05-23 16:35:07 +02:00
|
|
|
#include "qemu/module.h"
|
2012-11-14 21:54:06 +01:00
|
|
|
|
|
|
|
/****************************************************************************
|
|
|
|
* Q35 host
|
|
|
|
*/
|
|
|
|
|
2017-11-11 16:25:00 +01:00
|
|
|
#define Q35_PCI_HOST_HOLE64_SIZE_DEFAULT (1ULL << 35)
|
|
|
|
|
2013-07-01 12:18:23 +02:00
|
|
|
static void q35_host_realize(DeviceState *dev, Error **errp)
|
2012-11-14 21:54:06 +01:00
|
|
|
{
|
2013-07-01 12:18:22 +02:00
|
|
|
PCIHostState *pci = PCI_HOST_BRIDGE(dev);
|
|
|
|
Q35PCIHost *s = Q35_HOST_DEVICE(dev);
|
2013-07-01 12:18:23 +02:00
|
|
|
SysBusDevice *sbd = SYS_BUS_DEVICE(dev);
|
2012-11-14 21:54:06 +01:00
|
|
|
|
2023-02-13 17:19:57 +01:00
|
|
|
memory_region_add_subregion(s->mch.address_space_io,
|
|
|
|
MCH_HOST_BRIDGE_CONFIG_ADDR, &pci->conf_mem);
|
2013-07-01 12:18:23 +02:00
|
|
|
sysbus_init_ioports(sbd, MCH_HOST_BRIDGE_CONFIG_ADDR, 4);
|
2012-11-14 21:54:06 +01:00
|
|
|
|
2023-02-13 17:19:57 +01:00
|
|
|
memory_region_add_subregion(s->mch.address_space_io,
|
|
|
|
MCH_HOST_BRIDGE_CONFIG_DATA, &pci->data_mem);
|
2013-07-01 12:18:23 +02:00
|
|
|
sysbus_init_ioports(sbd, MCH_HOST_BRIDGE_CONFIG_DATA, 4);
|
2012-11-14 21:54:06 +01:00
|
|
|
|
2018-10-17 18:52:57 +02:00
|
|
|
/* register q35 0xcf8 port as coalesced pio */
|
|
|
|
memory_region_set_flush_coalesced(&pci->data_mem);
|
|
|
|
memory_region_add_coalescing(&pci->conf_mem, 0, 4);
|
|
|
|
|
2017-11-29 09:46:22 +01:00
|
|
|
pci->bus = pci_root_bus_new(DEVICE(s), "pcie.0",
|
|
|
|
s->mch.pci_address_space,
|
|
|
|
s->mch.address_space_io,
|
|
|
|
0, TYPE_PCIE_BUS);
|
2023-06-30 09:37:08 +02:00
|
|
|
|
qdev: Convert uses of qdev_set_parent_bus() with Coccinelle
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-10 07:32:00 +02:00
|
|
|
qdev_realize(DEVICE(&s->mch), BUS(pci->bus), &error_fatal);
|
2012-11-14 21:54:06 +01:00
|
|
|
}
|
|
|
|
|
2013-06-06 10:48:49 +02:00
|
|
|
static const char *q35_host_root_bus_path(PCIHostState *host_bridge,
|
|
|
|
PCIBus *rootbus)
|
|
|
|
{
|
2013-11-06 00:46:27 +01:00
|
|
|
Q35PCIHost *s = Q35_HOST_DEVICE(host_bridge);
|
|
|
|
|
|
|
|
/* For backwards compat with old device paths */
|
|
|
|
if (s->mch.short_root_bus) {
|
|
|
|
return "0000";
|
|
|
|
}
|
|
|
|
return "0000:00";
|
2013-06-06 10:48:49 +02:00
|
|
|
}
|
|
|
|
|
2013-07-29 16:47:57 +02:00
|
|
|
static void q35_host_get_pci_hole_start(Object *obj, Visitor *v,
|
qom: Swap 'name' next to visitor in ObjectPropertyAccessor
Similar to the previous patch, it's nice to have all functions
in the tree that involve a visitor and a name for conversion to
or from QAPI to consistently stick the 'name' parameter next
to the Visitor parameter.
Done by manually changing include/qom/object.h and qom/object.c,
then running this Coccinelle script and touching up the fallout
(Coccinelle insisted on adding some trailing whitespace).
@ rule1 @
identifier fn;
typedef Object, Visitor, Error;
identifier obj, v, opaque, name, errp;
@@
void fn
- (Object *obj, Visitor *v, void *opaque, const char *name,
+ (Object *obj, Visitor *v, const char *name, void *opaque,
Error **errp) { ... }
@@
identifier rule1.fn;
expression obj, v, opaque, name, errp;
@@
fn(obj, v,
- opaque, name,
+ name, opaque,
errp)
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <1454075341-13658-20-git-send-email-eblake@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
2016-01-29 14:48:55 +01:00
|
|
|
const char *name, void *opaque,
|
2013-07-29 16:47:57 +02:00
|
|
|
Error **errp)
|
|
|
|
{
|
|
|
|
Q35PCIHost *s = Q35_HOST_DEVICE(obj);
|
2016-07-01 13:47:47 +02:00
|
|
|
uint64_t val64;
|
|
|
|
uint32_t value;
|
2013-07-29 16:47:57 +02:00
|
|
|
|
2016-07-01 13:47:47 +02:00
|
|
|
val64 = range_is_empty(&s->mch.pci_hole)
|
|
|
|
? 0 : range_lob(&s->mch.pci_hole);
|
|
|
|
value = val64;
|
|
|
|
assert(value == val64);
|
qapi: Swap visit_* arguments for consistent 'name' placement
JSON uses "name":value, but many of our visitor interfaces were
called with visit_type_FOO(v, &value, name, errp). This can be
a bit confusing to have to mentally swap the parameter order to
match JSON order. It's particularly bad for visit_start_struct(),
where the 'name' parameter is smack in the middle of the
otherwise-related group of 'obj, kind, size' parameters! It's
time to do a global swap of the parameter ordering, so that the
'name' parameter is always immediately after the Visitor argument.
Additional reason in favor of the swap: the existing include/qjson.h
prefers listing 'name' first in json_prop_*(), and I have plans to
unify that file with the qapi visitors; listing 'name' first in
qapi will minimize churn to the (admittedly few) qjson.h clients.
Later patches will then fix docs, object.h, visitor-impl.h, and
those clients to match.
Done by first patching scripts/qapi*.py by hand to make generated
files do what I want, then by running the following Coccinelle
script to affect the rest of the code base:
$ spatch --sp-file script `git grep -l '\bvisit_' -- '**/*.[ch]'`
I then had to apply some touchups (Coccinelle insisted on TAB
indentation in visitor.h, and botched the signature of
visit_type_enum() by rewriting 'const char *const strings[]' to
the syntactically invalid 'const char*const[] strings'). The
movement of parameters is sufficient to provoke compiler errors
if any callers were missed.
// Part 1: Swap declaration order
@@
type TV, TErr, TObj, T1, T2;
identifier OBJ, ARG1, ARG2;
@@
void visit_start_struct
-(TV v, TObj OBJ, T1 ARG1, const char *name, T2 ARG2, TErr errp)
+(TV v, const char *name, TObj OBJ, T1 ARG1, T2 ARG2, TErr errp)
{ ... }
@@
type bool, TV, T1;
identifier ARG1;
@@
bool visit_optional
-(TV v, T1 ARG1, const char *name)
+(TV v, const char *name, T1 ARG1)
{ ... }
@@
type TV, TErr, TObj, T1;
identifier OBJ, ARG1;
@@
void visit_get_next_type
-(TV v, TObj OBJ, T1 ARG1, const char *name, TErr errp)
+(TV v, const char *name, TObj OBJ, T1 ARG1, TErr errp)
{ ... }
@@
type TV, TErr, TObj, T1, T2;
identifier OBJ, ARG1, ARG2;
@@
void visit_type_enum
-(TV v, TObj OBJ, T1 ARG1, T2 ARG2, const char *name, TErr errp)
+(TV v, const char *name, TObj OBJ, T1 ARG1, T2 ARG2, TErr errp)
{ ... }
@@
type TV, TErr, TObj;
identifier OBJ;
identifier VISIT_TYPE =~ "^visit_type_";
@@
void VISIT_TYPE
-(TV v, TObj OBJ, const char *name, TErr errp)
+(TV v, const char *name, TObj OBJ, TErr errp)
{ ... }
// Part 2: swap caller order
@@
expression V, NAME, OBJ, ARG1, ARG2, ERR;
identifier VISIT_TYPE =~ "^visit_type_";
@@
(
-visit_start_struct(V, OBJ, ARG1, NAME, ARG2, ERR)
+visit_start_struct(V, NAME, OBJ, ARG1, ARG2, ERR)
|
-visit_optional(V, ARG1, NAME)
+visit_optional(V, NAME, ARG1)
|
-visit_get_next_type(V, OBJ, ARG1, NAME, ERR)
+visit_get_next_type(V, NAME, OBJ, ARG1, ERR)
|
-visit_type_enum(V, OBJ, ARG1, ARG2, NAME, ERR)
+visit_type_enum(V, NAME, OBJ, ARG1, ARG2, ERR)
|
-VISIT_TYPE(V, OBJ, NAME, ERR)
+VISIT_TYPE(V, NAME, OBJ, ERR)
)
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <1454075341-13658-19-git-send-email-eblake@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
2016-01-29 14:48:54 +01:00
|
|
|
visit_type_uint32(v, name, &value, errp);
|
2013-07-29 16:47:57 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
static void q35_host_get_pci_hole_end(Object *obj, Visitor *v,
|
qom: Swap 'name' next to visitor in ObjectPropertyAccessor
Similar to the previous patch, it's nice to have all functions
in the tree that involve a visitor and a name for conversion to
or from QAPI to consistently stick the 'name' parameter next
to the Visitor parameter.
Done by manually changing include/qom/object.h and qom/object.c,
then running this Coccinelle script and touching up the fallout
(Coccinelle insisted on adding some trailing whitespace).
@ rule1 @
identifier fn;
typedef Object, Visitor, Error;
identifier obj, v, opaque, name, errp;
@@
void fn
- (Object *obj, Visitor *v, void *opaque, const char *name,
+ (Object *obj, Visitor *v, const char *name, void *opaque,
Error **errp) { ... }
@@
identifier rule1.fn;
expression obj, v, opaque, name, errp;
@@
fn(obj, v,
- opaque, name,
+ name, opaque,
errp)
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <1454075341-13658-20-git-send-email-eblake@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
2016-01-29 14:48:55 +01:00
|
|
|
const char *name, void *opaque,
|
2013-07-29 16:47:57 +02:00
|
|
|
Error **errp)
|
|
|
|
{
|
|
|
|
Q35PCIHost *s = Q35_HOST_DEVICE(obj);
|
2016-07-01 13:47:47 +02:00
|
|
|
uint64_t val64;
|
|
|
|
uint32_t value;
|
2013-07-29 16:47:57 +02:00
|
|
|
|
2016-07-01 13:47:47 +02:00
|
|
|
val64 = range_is_empty(&s->mch.pci_hole)
|
|
|
|
? 0 : range_upb(&s->mch.pci_hole) + 1;
|
|
|
|
value = val64;
|
|
|
|
assert(value == val64);
|
qapi: Swap visit_* arguments for consistent 'name' placement
JSON uses "name":value, but many of our visitor interfaces were
called with visit_type_FOO(v, &value, name, errp). This can be
a bit confusing to have to mentally swap the parameter order to
match JSON order. It's particularly bad for visit_start_struct(),
where the 'name' parameter is smack in the middle of the
otherwise-related group of 'obj, kind, size' parameters! It's
time to do a global swap of the parameter ordering, so that the
'name' parameter is always immediately after the Visitor argument.
Additional reason in favor of the swap: the existing include/qjson.h
prefers listing 'name' first in json_prop_*(), and I have plans to
unify that file with the qapi visitors; listing 'name' first in
qapi will minimize churn to the (admittedly few) qjson.h clients.
Later patches will then fix docs, object.h, visitor-impl.h, and
those clients to match.
Done by first patching scripts/qapi*.py by hand to make generated
files do what I want, then by running the following Coccinelle
script to affect the rest of the code base:
$ spatch --sp-file script `git grep -l '\bvisit_' -- '**/*.[ch]'`
I then had to apply some touchups (Coccinelle insisted on TAB
indentation in visitor.h, and botched the signature of
visit_type_enum() by rewriting 'const char *const strings[]' to
the syntactically invalid 'const char*const[] strings'). The
movement of parameters is sufficient to provoke compiler errors
if any callers were missed.
// Part 1: Swap declaration order
@@
type TV, TErr, TObj, T1, T2;
identifier OBJ, ARG1, ARG2;
@@
void visit_start_struct
-(TV v, TObj OBJ, T1 ARG1, const char *name, T2 ARG2, TErr errp)
+(TV v, const char *name, TObj OBJ, T1 ARG1, T2 ARG2, TErr errp)
{ ... }
@@
type bool, TV, T1;
identifier ARG1;
@@
bool visit_optional
-(TV v, T1 ARG1, const char *name)
+(TV v, const char *name, T1 ARG1)
{ ... }
@@
type TV, TErr, TObj, T1;
identifier OBJ, ARG1;
@@
void visit_get_next_type
-(TV v, TObj OBJ, T1 ARG1, const char *name, TErr errp)
+(TV v, const char *name, TObj OBJ, T1 ARG1, TErr errp)
{ ... }
@@
type TV, TErr, TObj, T1, T2;
identifier OBJ, ARG1, ARG2;
@@
void visit_type_enum
-(TV v, TObj OBJ, T1 ARG1, T2 ARG2, const char *name, TErr errp)
+(TV v, const char *name, TObj OBJ, T1 ARG1, T2 ARG2, TErr errp)
{ ... }
@@
type TV, TErr, TObj;
identifier OBJ;
identifier VISIT_TYPE =~ "^visit_type_";
@@
void VISIT_TYPE
-(TV v, TObj OBJ, const char *name, TErr errp)
+(TV v, const char *name, TObj OBJ, TErr errp)
{ ... }
// Part 2: swap caller order
@@
expression V, NAME, OBJ, ARG1, ARG2, ERR;
identifier VISIT_TYPE =~ "^visit_type_";
@@
(
-visit_start_struct(V, OBJ, ARG1, NAME, ARG2, ERR)
+visit_start_struct(V, NAME, OBJ, ARG1, ARG2, ERR)
|
-visit_optional(V, ARG1, NAME)
+visit_optional(V, NAME, ARG1)
|
-visit_get_next_type(V, OBJ, ARG1, NAME, ERR)
+visit_get_next_type(V, NAME, OBJ, ARG1, ERR)
|
-visit_type_enum(V, OBJ, ARG1, ARG2, NAME, ERR)
+visit_type_enum(V, NAME, OBJ, ARG1, ARG2, ERR)
|
-VISIT_TYPE(V, OBJ, NAME, ERR)
+VISIT_TYPE(V, NAME, OBJ, ERR)
)
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <1454075341-13658-19-git-send-email-eblake@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
2016-01-29 14:48:54 +01:00
|
|
|
visit_type_uint32(v, name, &value, errp);
|
2013-07-29 16:47:57 +02:00
|
|
|
}
|
|
|
|
|
2017-11-11 16:25:00 +01:00
|
|
|
/*
|
|
|
|
* The 64bit PCI hole start is set by the Guest firmware
|
|
|
|
* as the address of the first 64bit PCI MEM resource.
|
|
|
|
* If no PCI device has resources on the 64bit area,
|
|
|
|
* the 64bit PCI hole will start after "over 4G RAM" and the
|
|
|
|
* reserved space for memory hotplug if any.
|
|
|
|
*/
|
2018-09-27 23:24:37 +02:00
|
|
|
static uint64_t q35_host_get_pci_hole64_start_value(Object *obj)
|
2013-07-29 16:47:57 +02:00
|
|
|
{
|
2013-09-02 11:57:36 +02:00
|
|
|
PCIHostState *h = PCI_HOST_BRIDGE(obj);
|
2017-11-11 16:25:00 +01:00
|
|
|
Q35PCIHost *s = Q35_HOST_DEVICE(obj);
|
2013-09-02 11:57:36 +02:00
|
|
|
Range w64;
|
2016-07-01 13:47:47 +02:00
|
|
|
uint64_t value;
|
2013-09-02 11:57:36 +02:00
|
|
|
|
|
|
|
pci_bus_get_w64_range(h->bus, &w64);
|
2016-07-01 13:47:47 +02:00
|
|
|
value = range_is_empty(&w64) ? 0 : range_lob(&w64);
|
2017-11-11 16:25:00 +01:00
|
|
|
if (!value && s->pci_hole64_fix) {
|
|
|
|
value = pc_pci_hole64_start();
|
|
|
|
}
|
2018-09-27 23:24:37 +02:00
|
|
|
return value;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void q35_host_get_pci_hole64_start(Object *obj, Visitor *v,
|
|
|
|
const char *name, void *opaque,
|
|
|
|
Error **errp)
|
|
|
|
{
|
|
|
|
uint64_t hole64_start = q35_host_get_pci_hole64_start_value(obj);
|
|
|
|
|
|
|
|
visit_type_uint64(v, name, &hole64_start, errp);
|
2013-07-29 16:47:57 +02:00
|
|
|
}
|
|
|
|
|
2017-11-11 16:25:00 +01:00
|
|
|
/*
|
|
|
|
* The 64bit PCI hole end is set by the Guest firmware
|
|
|
|
* as the address of the last 64bit PCI MEM resource.
|
|
|
|
* Then it is expanded to the PCI_HOST_PROP_PCI_HOLE64_SIZE
|
|
|
|
* that can be configured by the user.
|
|
|
|
*/
|
2013-07-29 16:47:57 +02:00
|
|
|
static void q35_host_get_pci_hole64_end(Object *obj, Visitor *v,
|
qom: Swap 'name' next to visitor in ObjectPropertyAccessor
Similar to the previous patch, it's nice to have all functions
in the tree that involve a visitor and a name for conversion to
or from QAPI to consistently stick the 'name' parameter next
to the Visitor parameter.
Done by manually changing include/qom/object.h and qom/object.c,
then running this Coccinelle script and touching up the fallout
(Coccinelle insisted on adding some trailing whitespace).
@ rule1 @
identifier fn;
typedef Object, Visitor, Error;
identifier obj, v, opaque, name, errp;
@@
void fn
- (Object *obj, Visitor *v, void *opaque, const char *name,
+ (Object *obj, Visitor *v, const char *name, void *opaque,
Error **errp) { ... }
@@
identifier rule1.fn;
expression obj, v, opaque, name, errp;
@@
fn(obj, v,
- opaque, name,
+ name, opaque,
errp)
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <1454075341-13658-20-git-send-email-eblake@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
2016-01-29 14:48:55 +01:00
|
|
|
const char *name, void *opaque,
|
2013-07-29 16:47:57 +02:00
|
|
|
Error **errp)
|
|
|
|
{
|
2013-09-02 11:57:36 +02:00
|
|
|
PCIHostState *h = PCI_HOST_BRIDGE(obj);
|
2017-11-11 16:25:00 +01:00
|
|
|
Q35PCIHost *s = Q35_HOST_DEVICE(obj);
|
hw/pci-host/x86: extend the 64-bit PCI hole relative to the fw-assigned base
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-09-27 23:24:38 +02:00
|
|
|
uint64_t hole64_start = q35_host_get_pci_hole64_start_value(obj);
|
2013-09-02 11:57:36 +02:00
|
|
|
Range w64;
|
2017-11-11 16:25:00 +01:00
|
|
|
uint64_t value, hole64_end;
|
2013-07-29 16:47:57 +02:00
|
|
|
|
2013-09-02 11:57:36 +02:00
|
|
|
pci_bus_get_w64_range(h->bus, &w64);
|
2016-07-01 13:47:47 +02:00
|
|
|
value = range_is_empty(&w64) ? 0 : range_upb(&w64) + 1;
|
2017-11-11 16:25:00 +01:00
|
|
|
hole64_end = ROUND_UP(hole64_start + s->mch.pci_hole64_size, 1ULL << 30);
|
|
|
|
if (s->pci_hole64_fix && value < hole64_end) {
|
|
|
|
value = hole64_end;
|
|
|
|
}
|
2016-07-01 13:47:47 +02:00
|
|
|
visit_type_uint64(v, name, &value, errp);
|
2013-07-29 16:47:57 +02:00
|
|
|
}
|
|
|
|
|
2017-11-11 16:25:00 +01:00
|
|
|
/*
|
|
|
|
* NOTE: setting defaults for the mch.* fields in this table
|
|
|
|
* doesn't work, because mch is a separate QOM object that is
|
|
|
|
* zeroed by the object_initialize(&s->mch, ...) call inside
|
|
|
|
* q35_host_initfn(). The default values for those
|
|
|
|
* properties need to be initialized manually by
|
|
|
|
* q35_host_initfn() after the object_initialize() call.
|
|
|
|
*/
|
q35/mch: implement extended TSEG sizes
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-06-08 18:10:13 +02:00
|
|
|
static Property q35_host_props[] = {
|
2013-09-02 16:59:38 +02:00
|
|
|
DEFINE_PROP_UINT64(PCIE_HOST_MCFG_BASE, Q35PCIHost, parent_obj.base_addr,
|
2012-11-14 21:54:06 +01:00
|
|
|
MCH_HOST_BRIDGE_PCIEXBAR_DEFAULT),
|
2013-07-29 16:47:57 +02:00
|
|
|
DEFINE_PROP_SIZE(PCI_HOST_PROP_PCI_HOLE64_SIZE, Q35PCIHost,
|
2017-11-11 16:25:00 +01:00
|
|
|
mch.pci_hole64_size, Q35_PCI_HOST_HOLE64_SIZE_DEFAULT),
|
2013-11-06 00:46:27 +01:00
|
|
|
DEFINE_PROP_UINT32("short_root_bus", Q35PCIHost, mch.short_root_bus, 0),
|
2016-06-22 14:24:49 +02:00
|
|
|
DEFINE_PROP_SIZE(PCI_HOST_BELOW_4G_MEM_SIZE, Q35PCIHost,
|
|
|
|
mch.below_4g_mem_size, 0),
|
|
|
|
DEFINE_PROP_SIZE(PCI_HOST_ABOVE_4G_MEM_SIZE, Q35PCIHost,
|
|
|
|
mch.above_4g_mem_size, 0),
|
2017-11-11 16:25:00 +01:00
|
|
|
DEFINE_PROP_BOOL("x-pci-hole64-fix", Q35PCIHost, pci_hole64_fix, true),
|
2012-11-14 21:54:06 +01:00
|
|
|
DEFINE_PROP_END_OF_LIST(),
|
|
|
|
};
|
|
|
|
|
|
|
|
static void q35_host_class_init(ObjectClass *klass, void *data)
|
|
|
|
{
|
|
|
|
DeviceClass *dc = DEVICE_CLASS(klass);
|
2013-06-06 10:48:49 +02:00
|
|
|
PCIHostBridgeClass *hc = PCI_HOST_BRIDGE_CLASS(klass);
|
2012-11-14 21:54:06 +01:00
|
|
|
|
2013-06-06 10:48:49 +02:00
|
|
|
hc->root_bus_path = q35_host_root_bus_path;
|
2013-07-01 12:18:23 +02:00
|
|
|
dc->realize = q35_host_realize;
|
2020-01-10 16:30:32 +01:00
|
|
|
device_class_set_props(dc, q35_host_props);
|
2016-06-27 17:38:33 +02:00
|
|
|
/* Reason: needs to be wired up by pc_q35_init */
|
2017-05-03 22:35:44 +02:00
|
|
|
dc->user_creatable = false;
|
2013-07-29 16:17:45 +02:00
|
|
|
set_bit(DEVICE_CATEGORY_BRIDGE, dc->categories);
|
2013-05-30 10:35:23 +02:00
|
|
|
dc->fw_name = "pci";
|
2012-11-14 21:54:06 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
static void q35_host_initfn(Object *obj)
|
|
|
|
{
|
|
|
|
Q35PCIHost *s = Q35_HOST_DEVICE(obj);
|
2013-07-01 12:18:23 +02:00
|
|
|
PCIHostState *phb = PCI_HOST_BRIDGE(obj);
|
2020-02-04 14:16:01 +01:00
|
|
|
PCIExpressHost *pehb = PCIE_HOST_BRIDGE(obj);
|
2013-07-01 12:18:23 +02:00
|
|
|
|
|
|
|
memory_region_init_io(&phb->conf_mem, obj, &pci_host_conf_le_ops, phb,
|
|
|
|
"pci-conf-idx", 4);
|
|
|
|
memory_region_init_io(&phb->data_mem, obj, &pci_host_data_le_ops, phb,
|
|
|
|
"pci-conf-data", 4);
|
2012-11-14 21:54:06 +01:00
|
|
|
|
qom: Less verbose object_initialize_child()
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-10 07:32:25 +02:00
|
|
|
object_initialize_child(OBJECT(s), "mch", &s->mch, TYPE_MCH_PCI_DEVICE);
|
2017-06-07 18:36:11 +02:00
|
|
|
qdev_prop_set_int32(DEVICE(&s->mch), "addr", PCI_DEVFN(0, 0));
|
2012-11-14 21:54:06 +01:00
|
|
|
qdev_prop_set_bit(DEVICE(&s->mch), "multifunction", false);
|
2017-11-11 16:25:00 +01:00
|
|
|
/* mch's object_initialize resets the default value, set it again */
|
|
|
|
qdev_prop_set_uint64(DEVICE(s), PCI_HOST_PROP_PCI_HOLE64_SIZE,
|
|
|
|
Q35_PCI_HOST_HOLE64_SIZE_DEFAULT);
|
2017-06-07 18:36:06 +02:00
|
|
|
object_property_add(obj, PCI_HOST_PROP_PCI_HOLE_START, "uint32",
|
2013-07-29 16:47:57 +02:00
|
|
|
q35_host_get_pci_hole_start,
|
qom: Drop parameter @errp of object_property_add() & friends
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-05-05 17:29:22 +02:00
|
|
|
NULL, NULL, NULL);
|
2013-07-29 16:47:57 +02:00
|
|
|
|
2017-06-07 18:36:06 +02:00
|
|
|
object_property_add(obj, PCI_HOST_PROP_PCI_HOLE_END, "uint32",
|
2013-07-29 16:47:57 +02:00
|
|
|
q35_host_get_pci_hole_end,
|
qom: Drop parameter @errp of object_property_add() & friends
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-05-05 17:29:22 +02:00
|
|
|
NULL, NULL, NULL);
|
2013-07-29 16:47:57 +02:00
|
|
|
|
2017-06-07 18:36:06 +02:00
|
|
|
object_property_add(obj, PCI_HOST_PROP_PCI_HOLE64_START, "uint64",
|
2013-07-29 16:47:57 +02:00
|
|
|
q35_host_get_pci_hole64_start,
|
qom: Drop parameter @errp of object_property_add() & friends
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-05-05 17:29:22 +02:00
|
|
|
NULL, NULL, NULL);
|
2013-07-29 16:47:57 +02:00
|
|
|
|
2017-06-07 18:36:06 +02:00
|
|
|
object_property_add(obj, PCI_HOST_PROP_PCI_HOLE64_END, "uint64",
|
2013-07-29 16:47:57 +02:00
|
|
|
q35_host_get_pci_hole64_end,
|
qom: Drop parameter @errp of object_property_add() & friends
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-05-05 17:29:22 +02:00
|
|
|
NULL, NULL, NULL);
|
2013-07-29 16:47:57 +02:00
|
|
|
|
2020-02-04 14:16:01 +01:00
|
|
|
object_property_add_uint64_ptr(obj, PCIE_HOST_MCFG_SIZE,
|
qom: Drop parameter @errp of object_property_add() & friends
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-05-05 17:29:22 +02:00
|
|
|
&pehb->size, OBJ_PROP_FLAG_READ);
|
2013-09-10 09:16:02 +02:00
|
|
|
|
2023-06-30 09:37:09 +02:00
|
|
|
object_property_add_link(obj, PCI_HOST_PROP_RAM_MEM, TYPE_MEMORY_REGION,
|
2016-06-22 14:24:49 +02:00
|
|
|
(Object **) &s->mch.ram_memory,
|
qom: Drop parameter @errp of object_property_add() & friends
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-05-05 17:29:22 +02:00
|
|
|
qdev_prop_allow_set_link_before_realize, 0);
|
2016-06-22 14:24:49 +02:00
|
|
|
|
2023-06-30 09:37:09 +02:00
|
|
|
object_property_add_link(obj, PCI_HOST_PROP_PCI_MEM, TYPE_MEMORY_REGION,
|
2016-06-22 14:24:49 +02:00
|
|
|
(Object **) &s->mch.pci_address_space,
|
qom: Drop parameter @errp of object_property_add() & friends
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-05-05 17:29:22 +02:00
|
|
|
qdev_prop_allow_set_link_before_realize, 0);
|
2016-06-22 14:24:49 +02:00
|
|
|
|
2023-06-30 09:37:09 +02:00
|
|
|
object_property_add_link(obj, PCI_HOST_PROP_SYSTEM_MEM, TYPE_MEMORY_REGION,
|
2016-06-22 14:24:49 +02:00
|
|
|
(Object **) &s->mch.system_memory,
|
qom: Drop parameter @errp of object_property_add() & friends
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-05-05 17:29:22 +02:00
|
|
|
qdev_prop_allow_set_link_before_realize, 0);
|
2016-06-22 14:24:49 +02:00
|
|
|
|
2023-06-30 09:37:09 +02:00
|
|
|
object_property_add_link(obj, PCI_HOST_PROP_IO_MEM, TYPE_MEMORY_REGION,
|
2016-06-22 14:24:49 +02:00
|
|
|
(Object **) &s->mch.address_space_io,
|
qom: Drop parameter @errp of object_property_add() & friends
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-05-05 17:29:22 +02:00
|
|
|
qdev_prop_allow_set_link_before_realize, 0);
|
2012-11-14 21:54:06 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
static const TypeInfo q35_host_info = {
|
|
|
|
.name = TYPE_Q35_HOST_DEVICE,
|
|
|
|
.parent = TYPE_PCIE_HOST_BRIDGE,
|
|
|
|
.instance_size = sizeof(Q35PCIHost),
|
|
|
|
.instance_init = q35_host_initfn,
|
|
|
|
.class_init = q35_host_class_init,
|
|
|
|
};
|
|
|
|
|
|
|
|
/****************************************************************************
|
|
|
|
* MCH D0:F0
|
|
|
|
*/
|
|
|
|
|
2019-12-09 14:08:55 +01:00
|
|
|
static uint64_t blackhole_read(void *ptr, hwaddr reg, unsigned size)
|
2015-04-20 10:55:09 +02:00
|
|
|
{
|
|
|
|
return 0xffffffff;
|
|
|
|
}
|
|
|
|
|
2019-12-09 14:08:55 +01:00
|
|
|
static void blackhole_write(void *opaque, hwaddr addr, uint64_t val,
|
|
|
|
unsigned width)
|
2015-04-20 10:55:09 +02:00
|
|
|
{
|
|
|
|
/* nothing */
|
|
|
|
}
|
|
|
|
|
2019-12-09 14:08:55 +01:00
|
|
|
static const MemoryRegionOps blackhole_ops = {
|
|
|
|
.read = blackhole_read,
|
|
|
|
.write = blackhole_write,
|
2015-04-20 10:55:09 +02:00
|
|
|
.valid.min_access_size = 1,
|
|
|
|
.valid.max_access_size = 4,
|
|
|
|
.impl.min_access_size = 4,
|
|
|
|
.impl.max_access_size = 4,
|
|
|
|
.endianness = DEVICE_LITTLE_ENDIAN,
|
|
|
|
};
|
|
|
|
|
2012-11-14 21:54:06 +01:00
|
|
|
/* PCIe MMCFG */
|
|
|
|
static void mch_update_pciexbar(MCHPCIState *mch)
|
|
|
|
{
|
2013-07-01 12:18:22 +02:00
|
|
|
PCIDevice *pci_dev = PCI_DEVICE(mch);
|
|
|
|
BusState *bus = qdev_get_parent_bus(DEVICE(mch));
|
|
|
|
PCIExpressHost *pehb = PCIE_HOST_BRIDGE(bus->parent);
|
2012-11-14 21:54:06 +01:00
|
|
|
|
|
|
|
uint64_t pciexbar;
|
|
|
|
int enable;
|
|
|
|
uint64_t addr;
|
|
|
|
uint64_t addr_mask;
|
|
|
|
uint32_t length;
|
|
|
|
|
|
|
|
pciexbar = pci_get_quad(pci_dev->config + MCH_HOST_BRIDGE_PCIEXBAR);
|
|
|
|
enable = pciexbar & MCH_HOST_BRIDGE_PCIEXBAREN;
|
|
|
|
addr_mask = MCH_HOST_BRIDGE_PCIEXBAR_ADMSK;
|
|
|
|
switch (pciexbar & MCH_HOST_BRIDGE_PCIEXBAR_LENGTH_MASK) {
|
|
|
|
case MCH_HOST_BRIDGE_PCIEXBAR_LENGTH_256M:
|
|
|
|
length = 256 * 1024 * 1024;
|
|
|
|
break;
|
|
|
|
case MCH_HOST_BRIDGE_PCIEXBAR_LENGTH_128M:
|
|
|
|
length = 128 * 1024 * 1024;
|
|
|
|
addr_mask |= MCH_HOST_BRIDGE_PCIEXBAR_128ADMSK |
|
|
|
|
MCH_HOST_BRIDGE_PCIEXBAR_64ADMSK;
|
|
|
|
break;
|
|
|
|
case MCH_HOST_BRIDGE_PCIEXBAR_LENGTH_64M:
|
|
|
|
length = 64 * 1024 * 1024;
|
|
|
|
addr_mask |= MCH_HOST_BRIDGE_PCIEXBAR_64ADMSK;
|
|
|
|
break;
|
|
|
|
case MCH_HOST_BRIDGE_PCIEXBAR_LENGTH_RVD:
|
2021-05-26 16:24:38 +02:00
|
|
|
qemu_log_mask(LOG_GUEST_ERROR, "Q35: Reserved PCIEXBAR LENGTH\n");
|
|
|
|
return;
|
2012-11-14 21:54:06 +01:00
|
|
|
default:
|
|
|
|
abort();
|
|
|
|
}
|
|
|
|
addr = pciexbar & addr_mask;
|
2013-07-01 12:18:22 +02:00
|
|
|
pcie_host_mmcfg_update(pehb, enable, addr, length);
|
2012-11-14 21:54:06 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/* PAM */
|
|
|
|
static void mch_update_pam(MCHPCIState *mch)
|
|
|
|
{
|
2013-07-01 12:18:22 +02:00
|
|
|
PCIDevice *pd = PCI_DEVICE(mch);
|
2012-11-14 21:54:06 +01:00
|
|
|
int i;
|
|
|
|
|
|
|
|
memory_region_transaction_begin();
|
|
|
|
for (i = 0; i < 13; i++) {
|
|
|
|
pam_update(&mch->pam_regions[i], i,
|
2018-07-05 17:58:10 +02:00
|
|
|
pd->config[MCH_HOST_BRIDGE_PAM0 + DIV_ROUND_UP(i, 2)]);
|
2012-11-14 21:54:06 +01:00
|
|
|
}
|
|
|
|
memory_region_transaction_commit();
|
|
|
|
}
|
|
|
|
|
|
|
|
/* SMRAM */
|
|
|
|
static void mch_update_smram(MCHPCIState *mch)
|
|
|
|
{
|
2013-07-01 12:18:22 +02:00
|
|
|
PCIDevice *pd = PCI_DEVICE(mch);
|
2015-03-31 17:13:01 +02:00
|
|
|
bool h_smrame = (pd->config[MCH_HOST_BRIDGE_ESMRAMC] & MCH_HOST_BRIDGE_ESMRAMC_H_SMRAME);
|
2015-04-20 10:55:09 +02:00
|
|
|
uint32_t tseg_size;
|
2013-07-01 12:18:22 +02:00
|
|
|
|
2015-04-14 14:03:22 +02:00
|
|
|
/* implement SMRAM.D_LCK */
|
|
|
|
if (pd->config[MCH_HOST_BRIDGE_SMRAM] & MCH_HOST_BRIDGE_SMRAM_D_LCK) {
|
|
|
|
pd->config[MCH_HOST_BRIDGE_SMRAM] &= ~MCH_HOST_BRIDGE_SMRAM_D_OPEN;
|
|
|
|
pd->wmask[MCH_HOST_BRIDGE_SMRAM] = MCH_HOST_BRIDGE_SMRAM_WMASK_LCK;
|
|
|
|
pd->wmask[MCH_HOST_BRIDGE_ESMRAMC] = MCH_HOST_BRIDGE_ESMRAMC_WMASK_LCK;
|
|
|
|
}
|
|
|
|
|
2012-11-14 21:54:06 +01:00
|
|
|
memory_region_transaction_begin();
|
2015-03-31 17:13:01 +02:00
|
|
|
|
|
|
|
if (pd->config[MCH_HOST_BRIDGE_SMRAM] & SMRAM_D_OPEN) {
|
|
|
|
/* Hide (!) low SMRAM if H_SMRAME = 1 */
|
|
|
|
memory_region_set_enabled(&mch->smram_region, h_smrame);
|
|
|
|
/* Show high SMRAM if H_SMRAME = 1 */
|
|
|
|
memory_region_set_enabled(&mch->open_high_smram, h_smrame);
|
|
|
|
} else {
|
|
|
|
/* Hide high SMRAM and low SMRAM */
|
|
|
|
memory_region_set_enabled(&mch->smram_region, true);
|
|
|
|
memory_region_set_enabled(&mch->open_high_smram, false);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (pd->config[MCH_HOST_BRIDGE_SMRAM] & SMRAM_G_SMRAME) {
|
|
|
|
memory_region_set_enabled(&mch->low_smram, !h_smrame);
|
|
|
|
memory_region_set_enabled(&mch->high_smram, h_smrame);
|
|
|
|
} else {
|
|
|
|
memory_region_set_enabled(&mch->low_smram, false);
|
|
|
|
memory_region_set_enabled(&mch->high_smram, false);
|
|
|
|
}
|
|
|
|
|
2022-06-15 05:45:01 +02:00
|
|
|
if ((pd->config[MCH_HOST_BRIDGE_ESMRAMC] & MCH_HOST_BRIDGE_ESMRAMC_T_EN) &&
|
|
|
|
(pd->config[MCH_HOST_BRIDGE_SMRAM] & SMRAM_G_SMRAME)) {
|
2015-04-20 10:55:09 +02:00
|
|
|
switch (pd->config[MCH_HOST_BRIDGE_ESMRAMC] &
|
|
|
|
MCH_HOST_BRIDGE_ESMRAMC_TSEG_SZ_MASK) {
|
|
|
|
case MCH_HOST_BRIDGE_ESMRAMC_TSEG_SZ_1MB:
|
|
|
|
tseg_size = 1024 * 1024;
|
|
|
|
break;
|
|
|
|
case MCH_HOST_BRIDGE_ESMRAMC_TSEG_SZ_2MB:
|
|
|
|
tseg_size = 1024 * 1024 * 2;
|
|
|
|
break;
|
|
|
|
case MCH_HOST_BRIDGE_ESMRAMC_TSEG_SZ_8MB:
|
|
|
|
tseg_size = 1024 * 1024 * 8;
|
|
|
|
break;
|
|
|
|
default:
|
q35/mch: implement extended TSEG sizes
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-06-08 18:10:13 +02:00
|
|
|
tseg_size = 1024 * 1024 * (uint32_t)mch->ext_tseg_mbytes;
|
2015-04-20 10:55:09 +02:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
tseg_size = 0;
|
|
|
|
}
|
|
|
|
memory_region_del_subregion(mch->system_memory, &mch->tseg_blackhole);
|
|
|
|
memory_region_set_enabled(&mch->tseg_blackhole, tseg_size);
|
|
|
|
memory_region_set_size(&mch->tseg_blackhole, tseg_size);
|
|
|
|
memory_region_add_subregion_overlap(mch->system_memory,
|
|
|
|
mch->below_4g_mem_size - tseg_size,
|
|
|
|
&mch->tseg_blackhole, 1);
|
|
|
|
|
|
|
|
memory_region_set_enabled(&mch->tseg_window, tseg_size);
|
|
|
|
memory_region_set_size(&mch->tseg_window, tseg_size);
|
|
|
|
memory_region_set_address(&mch->tseg_window,
|
|
|
|
mch->below_4g_mem_size - tseg_size);
|
|
|
|
memory_region_set_alias_offset(&mch->tseg_window,
|
|
|
|
mch->below_4g_mem_size - tseg_size);
|
|
|
|
|
2012-11-14 21:54:06 +01:00
|
|
|
memory_region_transaction_commit();
|
|
|
|
}
|
|
|
|
|
q35/mch: implement extended TSEG sizes
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-06-08 18:10:13 +02:00
|
|
|
static void mch_update_ext_tseg_mbytes(MCHPCIState *mch)
|
|
|
|
{
|
|
|
|
PCIDevice *pd = PCI_DEVICE(mch);
|
|
|
|
uint8_t *reg = pd->config + MCH_HOST_BRIDGE_EXT_TSEG_MBYTES;
|
|
|
|
|
|
|
|
if (mch->ext_tseg_mbytes > 0 &&
|
|
|
|
pci_get_word(reg) == MCH_HOST_BRIDGE_EXT_TSEG_MBYTES_QUERY) {
|
|
|
|
pci_set_word(reg, mch->ext_tseg_mbytes);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-12-09 14:08:55 +01:00
|
|
|
static void mch_update_smbase_smram(MCHPCIState *mch)
|
|
|
|
{
|
|
|
|
PCIDevice *pd = PCI_DEVICE(mch);
|
|
|
|
uint8_t *reg = pd->config + MCH_HOST_BRIDGE_F_SMBASE;
|
|
|
|
bool lck;
|
|
|
|
|
|
|
|
if (!mch->has_smram_at_smbase) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (*reg == MCH_HOST_BRIDGE_F_SMBASE_QUERY) {
|
|
|
|
pd->wmask[MCH_HOST_BRIDGE_F_SMBASE] =
|
|
|
|
MCH_HOST_BRIDGE_F_SMBASE_LCK;
|
|
|
|
*reg = MCH_HOST_BRIDGE_F_SMBASE_IN_RAM;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* default/reset state, discard written value
|
|
|
|
* which will disable SMRAM balackhole at SMBASE
|
|
|
|
*/
|
|
|
|
if (pd->wmask[MCH_HOST_BRIDGE_F_SMBASE] == 0xff) {
|
|
|
|
*reg = 0x00;
|
|
|
|
}
|
|
|
|
|
|
|
|
memory_region_transaction_begin();
|
|
|
|
if (*reg & MCH_HOST_BRIDGE_F_SMBASE_LCK) {
|
|
|
|
/* disable all writes */
|
|
|
|
pd->wmask[MCH_HOST_BRIDGE_F_SMBASE] &=
|
|
|
|
~MCH_HOST_BRIDGE_F_SMBASE_LCK;
|
|
|
|
*reg = MCH_HOST_BRIDGE_F_SMBASE_LCK;
|
|
|
|
lck = true;
|
|
|
|
} else {
|
|
|
|
lck = false;
|
|
|
|
}
|
|
|
|
memory_region_set_enabled(&mch->smbase_blackhole, lck);
|
|
|
|
memory_region_set_enabled(&mch->smbase_window, lck);
|
|
|
|
memory_region_transaction_commit();
|
|
|
|
}
|
|
|
|
|
2012-11-14 21:54:06 +01:00
|
|
|
static void mch_write_config(PCIDevice *d,
|
|
|
|
uint32_t address, uint32_t val, int len)
|
|
|
|
{
|
|
|
|
MCHPCIState *mch = MCH_PCI_DEVICE(d);
|
|
|
|
|
|
|
|
pci_default_write_config(d, address, val, len);
|
|
|
|
|
|
|
|
if (ranges_overlap(address, len, MCH_HOST_BRIDGE_PAM0,
|
|
|
|
MCH_HOST_BRIDGE_PAM_SIZE)) {
|
|
|
|
mch_update_pam(mch);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (ranges_overlap(address, len, MCH_HOST_BRIDGE_PCIEXBAR,
|
|
|
|
MCH_HOST_BRIDGE_PCIEXBAR_SIZE)) {
|
|
|
|
mch_update_pciexbar(mch);
|
|
|
|
}
|
|
|
|
|
2014-02-28 11:28:03 +01:00
|
|
|
if (ranges_overlap(address, len, MCH_HOST_BRIDGE_SMRAM,
|
|
|
|
MCH_HOST_BRIDGE_SMRAM_SIZE)) {
|
2012-11-14 21:54:06 +01:00
|
|
|
mch_update_smram(mch);
|
|
|
|
}
|
q35/mch: implement extended TSEG sizes
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-06-08 18:10:13 +02:00
|
|
|
|
|
|
|
if (ranges_overlap(address, len, MCH_HOST_BRIDGE_EXT_TSEG_MBYTES,
|
|
|
|
MCH_HOST_BRIDGE_EXT_TSEG_MBYTES_SIZE)) {
|
|
|
|
mch_update_ext_tseg_mbytes(mch);
|
|
|
|
}
|
2019-12-09 14:08:55 +01:00
|
|
|
|
|
|
|
if (ranges_overlap(address, len, MCH_HOST_BRIDGE_F_SMBASE, 1)) {
|
|
|
|
mch_update_smbase_smram(mch);
|
|
|
|
}
|
2012-11-14 21:54:06 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
static void mch_update(MCHPCIState *mch)
|
|
|
|
{
|
|
|
|
mch_update_pciexbar(mch);
|
|
|
|
mch_update_pam(mch);
|
|
|
|
mch_update_smram(mch);
|
q35/mch: implement extended TSEG sizes
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-06-08 18:10:13 +02:00
|
|
|
mch_update_ext_tseg_mbytes(mch);
|
2019-12-09 14:08:55 +01:00
|
|
|
mch_update_smbase_smram(mch);
|
2019-06-07 09:34:29 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* pci hole goes from end-of-low-ram to io-apic.
|
|
|
|
* mmconfig will be excluded by the dsdt builder.
|
|
|
|
*/
|
|
|
|
range_set_bounds(&mch->pci_hole,
|
|
|
|
mch->below_4g_mem_size,
|
|
|
|
IO_APIC_DEFAULT_ADDRESS - 1);
|
2012-11-14 21:54:06 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
static int mch_post_load(void *opaque, int version_id)
|
|
|
|
{
|
|
|
|
MCHPCIState *mch = opaque;
|
|
|
|
mch_update(mch);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static const VMStateDescription vmstate_mch = {
|
|
|
|
.name = "mch",
|
|
|
|
.version_id = 1,
|
|
|
|
.minimum_version_id = 1,
|
|
|
|
.post_load = mch_post_load,
|
2014-04-16 15:32:32 +02:00
|
|
|
.fields = (VMStateField[]) {
|
2013-07-01 12:18:22 +02:00
|
|
|
VMSTATE_PCI_DEVICE(parent_obj, MCHPCIState),
|
2015-03-31 14:12:25 +02:00
|
|
|
/* Used to be smm_enabled, which was basically always zero because
|
|
|
|
* SeaBIOS hardly uses SMM. SMRAM is now handled by CPU code.
|
|
|
|
*/
|
|
|
|
VMSTATE_UNUSED(1),
|
2012-11-14 21:54:06 +01:00
|
|
|
VMSTATE_END_OF_LIST()
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
static void mch_reset(DeviceState *qdev)
|
|
|
|
{
|
|
|
|
PCIDevice *d = PCI_DEVICE(qdev);
|
|
|
|
MCHPCIState *mch = MCH_PCI_DEVICE(d);
|
|
|
|
|
|
|
|
pci_set_quad(d->config + MCH_HOST_BRIDGE_PCIEXBAR,
|
|
|
|
MCH_HOST_BRIDGE_PCIEXBAR_DEFAULT);
|
|
|
|
|
2014-02-28 11:28:03 +01:00
|
|
|
d->config[MCH_HOST_BRIDGE_SMRAM] = MCH_HOST_BRIDGE_SMRAM_DEFAULT;
|
2015-04-15 16:43:24 +02:00
|
|
|
d->config[MCH_HOST_BRIDGE_ESMRAMC] = MCH_HOST_BRIDGE_ESMRAMC_DEFAULT;
|
2015-04-15 16:48:12 +02:00
|
|
|
d->wmask[MCH_HOST_BRIDGE_SMRAM] = MCH_HOST_BRIDGE_SMRAM_WMASK;
|
|
|
|
d->wmask[MCH_HOST_BRIDGE_ESMRAMC] = MCH_HOST_BRIDGE_ESMRAMC_WMASK;
|
2012-11-14 21:54:06 +01:00
|
|
|
|
q35/mch: implement extended TSEG sizes
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-06-08 18:10:13 +02:00
|
|
|
if (mch->ext_tseg_mbytes > 0) {
|
|
|
|
pci_set_word(d->config + MCH_HOST_BRIDGE_EXT_TSEG_MBYTES,
|
|
|
|
MCH_HOST_BRIDGE_EXT_TSEG_MBYTES_QUERY);
|
|
|
|
}
|
|
|
|
|
2019-12-09 14:08:55 +01:00
|
|
|
d->config[MCH_HOST_BRIDGE_F_SMBASE] = 0;
|
|
|
|
d->wmask[MCH_HOST_BRIDGE_F_SMBASE] = 0xff;
|
|
|
|
|
2012-11-14 21:54:06 +01:00
|
|
|
mch_update(mch);
|
|
|
|
}
|
|
|
|
|
2015-01-19 15:52:30 +01:00
|
|
|
static void mch_realize(PCIDevice *d, Error **errp)
|
2012-11-14 21:54:06 +01:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
MCHPCIState *mch = MCH_PCI_DEVICE(d);
|
2013-10-29 13:57:34 +01:00
|
|
|
|
q35/mch: implement extended TSEG sizes
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-06-08 18:10:13 +02:00
|
|
|
if (mch->ext_tseg_mbytes > MCH_HOST_BRIDGE_EXT_TSEG_MBYTES_MAX) {
|
|
|
|
error_setg(errp, "invalid extended-tseg-mbytes value: %" PRIu16,
|
|
|
|
mch->ext_tseg_mbytes);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2013-10-29 13:57:34 +01:00
|
|
|
/* setup pci memory mapping */
|
2023-01-05 18:38:26 +01:00
|
|
|
pc_pci_as_mapping_init(mch->system_memory, mch->pci_address_space);
|
2013-10-29 13:57:34 +01:00
|
|
|
|
2015-03-31 14:10:22 +02:00
|
|
|
/* if *disabled* show SMRAM to all CPUs */
|
2013-06-07 03:25:08 +02:00
|
|
|
memory_region_init_alias(&mch->smram_region, OBJECT(mch), "smram-region",
|
2018-04-25 11:52:23 +02:00
|
|
|
mch->pci_address_space, MCH_HOST_BRIDGE_SMRAM_C_BASE,
|
|
|
|
MCH_HOST_BRIDGE_SMRAM_C_SIZE);
|
|
|
|
memory_region_add_subregion_overlap(mch->system_memory, MCH_HOST_BRIDGE_SMRAM_C_BASE,
|
2012-11-14 21:54:06 +01:00
|
|
|
&mch->smram_region, 1);
|
2015-03-31 14:10:22 +02:00
|
|
|
memory_region_set_enabled(&mch->smram_region, true);
|
|
|
|
|
2015-03-31 17:13:01 +02:00
|
|
|
memory_region_init_alias(&mch->open_high_smram, OBJECT(mch), "smram-open-high",
|
2018-04-25 11:52:23 +02:00
|
|
|
mch->ram_memory, MCH_HOST_BRIDGE_SMRAM_C_BASE,
|
|
|
|
MCH_HOST_BRIDGE_SMRAM_C_SIZE);
|
2015-03-31 17:13:01 +02:00
|
|
|
memory_region_add_subregion_overlap(mch->system_memory, 0xfeda0000,
|
|
|
|
&mch->open_high_smram, 1);
|
|
|
|
memory_region_set_enabled(&mch->open_high_smram, false);
|
|
|
|
|
2015-03-31 14:10:22 +02:00
|
|
|
/* smram, as seen by SMM CPUs */
|
2020-06-01 16:29:27 +02:00
|
|
|
memory_region_init(&mch->smram, OBJECT(mch), "smram", 4 * GiB);
|
2015-03-31 14:10:22 +02:00
|
|
|
memory_region_set_enabled(&mch->smram, true);
|
|
|
|
memory_region_init_alias(&mch->low_smram, OBJECT(mch), "smram-low",
|
2018-04-25 11:52:23 +02:00
|
|
|
mch->ram_memory, MCH_HOST_BRIDGE_SMRAM_C_BASE,
|
|
|
|
MCH_HOST_BRIDGE_SMRAM_C_SIZE);
|
2015-03-31 14:10:22 +02:00
|
|
|
memory_region_set_enabled(&mch->low_smram, true);
|
2018-04-25 11:52:23 +02:00
|
|
|
memory_region_add_subregion(&mch->smram, MCH_HOST_BRIDGE_SMRAM_C_BASE,
|
|
|
|
&mch->low_smram);
|
2015-03-31 17:13:01 +02:00
|
|
|
memory_region_init_alias(&mch->high_smram, OBJECT(mch), "smram-high",
|
2018-04-25 11:52:23 +02:00
|
|
|
mch->ram_memory, MCH_HOST_BRIDGE_SMRAM_C_BASE,
|
|
|
|
MCH_HOST_BRIDGE_SMRAM_C_SIZE);
|
2015-03-31 17:13:01 +02:00
|
|
|
memory_region_set_enabled(&mch->high_smram, true);
|
|
|
|
memory_region_add_subregion(&mch->smram, 0xfeda0000, &mch->high_smram);
|
2015-04-20 10:55:09 +02:00
|
|
|
|
|
|
|
memory_region_init_io(&mch->tseg_blackhole, OBJECT(mch),
|
2019-12-09 14:08:55 +01:00
|
|
|
&blackhole_ops, NULL,
|
2015-04-20 10:55:09 +02:00
|
|
|
"tseg-blackhole", 0);
|
|
|
|
memory_region_set_enabled(&mch->tseg_blackhole, false);
|
|
|
|
memory_region_add_subregion_overlap(mch->system_memory,
|
|
|
|
mch->below_4g_mem_size,
|
|
|
|
&mch->tseg_blackhole, 1);
|
|
|
|
|
|
|
|
memory_region_init_alias(&mch->tseg_window, OBJECT(mch), "tseg-window",
|
|
|
|
mch->ram_memory, mch->below_4g_mem_size, 0);
|
|
|
|
memory_region_set_enabled(&mch->tseg_window, false);
|
|
|
|
memory_region_add_subregion(&mch->smram, mch->below_4g_mem_size,
|
|
|
|
&mch->tseg_window);
|
2019-12-09 14:08:55 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* This is not what hardware does, so it's QEMU specific hack.
|
|
|
|
* See commit message for details.
|
|
|
|
*/
|
|
|
|
memory_region_init_io(&mch->smbase_blackhole, OBJECT(mch), &blackhole_ops,
|
|
|
|
NULL, "smbase-blackhole",
|
|
|
|
MCH_HOST_BRIDGE_SMBASE_SIZE);
|
|
|
|
memory_region_set_enabled(&mch->smbase_blackhole, false);
|
|
|
|
memory_region_add_subregion_overlap(mch->system_memory,
|
|
|
|
MCH_HOST_BRIDGE_SMBASE_ADDR,
|
|
|
|
&mch->smbase_blackhole, 1);
|
|
|
|
|
|
|
|
memory_region_init_alias(&mch->smbase_window, OBJECT(mch),
|
|
|
|
"smbase-window", mch->ram_memory,
|
|
|
|
MCH_HOST_BRIDGE_SMBASE_ADDR,
|
|
|
|
MCH_HOST_BRIDGE_SMBASE_SIZE);
|
|
|
|
memory_region_set_enabled(&mch->smbase_window, false);
|
|
|
|
memory_region_add_subregion(&mch->smram, MCH_HOST_BRIDGE_SMBASE_ADDR,
|
|
|
|
&mch->smbase_window);
|
|
|
|
|
2015-03-31 14:10:22 +02:00
|
|
|
object_property_add_const_link(qdev_get_machine(), "smram",
|
qom: Drop parameter @errp of object_property_add() & friends
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-05-05 17:29:22 +02:00
|
|
|
OBJECT(&mch->smram));
|
2015-03-31 14:10:22 +02:00
|
|
|
|
2023-02-13 17:20:02 +01:00
|
|
|
init_pam(&mch->pam_regions[0], OBJECT(mch), mch->ram_memory,
|
|
|
|
mch->system_memory, mch->pci_address_space,
|
2014-08-16 07:55:41 +02:00
|
|
|
PAM_BIOS_BASE, PAM_BIOS_SIZE);
|
2020-12-02 14:20:38 +01:00
|
|
|
for (i = 0; i < ARRAY_SIZE(mch->pam_regions) - 1; ++i) {
|
2023-02-13 17:20:02 +01:00
|
|
|
init_pam(&mch->pam_regions[i + 1], OBJECT(mch), mch->ram_memory,
|
|
|
|
mch->system_memory, mch->pci_address_space,
|
2014-08-16 07:55:41 +02:00
|
|
|
PAM_EXPAN_BASE + i * PAM_EXPAN_SIZE, PAM_EXPAN_SIZE);
|
2012-11-14 21:54:06 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-07-24 17:56:10 +02:00
|
|
|
uint64_t mch_mcfg_base(void)
|
|
|
|
{
|
|
|
|
bool ambiguous;
|
|
|
|
Object *o = object_resolve_path_type("", TYPE_MCH_PCI_DEVICE, &ambiguous);
|
|
|
|
if (!o) {
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
return MCH_HOST_BRIDGE_PCIEXBAR_DEFAULT;
|
|
|
|
}
|
|
|
|
|
q35/mch: implement extended TSEG sizes
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-06-08 18:10:13 +02:00
|
|
|
static Property mch_props[] = {
|
|
|
|
DEFINE_PROP_UINT16("extended-tseg-mbytes", MCHPCIState, ext_tseg_mbytes,
|
|
|
|
16),
|
2019-12-09 14:08:55 +01:00
|
|
|
DEFINE_PROP_BOOL("smbase-smram", MCHPCIState, has_smram_at_smbase, true),
|
q35/mch: implement extended TSEG sizes
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-06-08 18:10:13 +02:00
|
|
|
DEFINE_PROP_END_OF_LIST(),
|
|
|
|
};
|
|
|
|
|
2012-11-14 21:54:06 +01:00
|
|
|
static void mch_class_init(ObjectClass *klass, void *data)
|
|
|
|
{
|
|
|
|
PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
|
|
|
|
DeviceClass *dc = DEVICE_CLASS(klass);
|
|
|
|
|
2015-01-19 15:52:30 +01:00
|
|
|
k->realize = mch_realize;
|
2012-11-14 21:54:06 +01:00
|
|
|
k->config_write = mch_write_config;
|
|
|
|
dc->reset = mch_reset;
|
2020-01-10 16:30:32 +01:00
|
|
|
device_class_set_props(dc, mch_props);
|
2013-07-29 16:17:45 +02:00
|
|
|
set_bit(DEVICE_CATEGORY_BRIDGE, dc->categories);
|
2012-11-14 21:54:06 +01:00
|
|
|
dc->desc = "Host bridge";
|
|
|
|
dc->vmsd = &vmstate_mch;
|
|
|
|
k->vendor_id = PCI_VENDOR_ID_INTEL;
|
2018-08-30 12:57:57 +02:00
|
|
|
/*
|
|
|
|
* The 'q35' machine type implements an Intel Series 3 chipset,
|
|
|
|
* of which there are several variants. The key difference between
|
|
|
|
* the 82P35 MCH ('p35') and 82Q35 GMCH ('q35') 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.
|
|
|
|
*/
|
|
|
|
k->device_id = PCI_DEVICE_ID_INTEL_P35_MCH;
|
2013-09-02 15:43:36 +02:00
|
|
|
k->revision = MCH_HOST_BRIDGE_REVISION_DEFAULT;
|
2012-11-14 21:54:06 +01:00
|
|
|
k->class_id = PCI_CLASS_BRIDGE_HOST;
|
pci-host: Consistently set cannot_instantiate_with_device_add_yet
Many PCI host bridges consist of a sysbus device and a PCI device.
You need both for the thing to work. Arguably, these bridges should
be modelled as a single, composite devices instead of pairs of
seemingly independent devices you can only use together, but we're not
there, yet.
Since the sysbus part can't be instantiated with device_add, yet,
permitting it with the PCI part is useless. We shouldn't offer
useless options to the user, so let's set
cannot_instantiate_with_device_add_yet for them.
It's already set for Bonito, Grackle, i440FX and Raven. Document why.
Set it for the others: dec-21154, e500-host-bridge, gt64120_pci, mch,
pbm-pci, ppc4xx-host-bridge, sh_pci_host, u3-agp, uni-north-agp,
uni-north-internal-pci, uni-north-pci, and versatile_pci_host.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Marcel Apfelbaum <marcel.a@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
2013-11-28 17:26:58 +01:00
|
|
|
/*
|
|
|
|
* PCI-facing part of the host bridge, not usable without the
|
|
|
|
* host-facing part, which can't be device_add'ed, yet.
|
|
|
|
*/
|
2017-05-03 22:35:44 +02:00
|
|
|
dc->user_creatable = false;
|
2012-11-14 21:54:06 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
static const TypeInfo mch_info = {
|
|
|
|
.name = TYPE_MCH_PCI_DEVICE,
|
|
|
|
.parent = TYPE_PCI_DEVICE,
|
|
|
|
.instance_size = sizeof(MCHPCIState),
|
|
|
|
.class_init = mch_class_init,
|
2017-09-27 21:56:34 +02:00
|
|
|
.interfaces = (InterfaceInfo[]) {
|
|
|
|
{ INTERFACE_CONVENTIONAL_PCI_DEVICE },
|
|
|
|
{ },
|
|
|
|
},
|
2012-11-14 21:54:06 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
static void q35_register(void)
|
|
|
|
{
|
|
|
|
type_register_static(&mch_info);
|
|
|
|
type_register_static(&q35_host_info);
|
|
|
|
}
|
|
|
|
|
|
|
|
type_init(q35_register);
|