|
From: | Marcel Apfelbaum |
Subject: | Re: [Qemu-devel] [PATCH 1/8] machine: query iommu machine property rather than qemu opts |
Date: | Wed, 04 Feb 2015 21:30:30 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 |
On 02/04/2015 06:47 PM, Markus Armbruster wrote:
Marcel Apfelbaum <address@hidden> writes:Fixes a QEMU crash when passing iommu parameter in command line. Signed-off-by: Marcel Apfelbaum <address@hidden> --- hw/core/machine.c | 5 +++++ hw/pci-host/q35.c | 2 +- include/hw/boards.h | 1 + 3 files changed, 7 insertions(+), 1 deletion(-) diff --git a/hw/core/machine.c b/hw/core/machine.c index fbd91be..096eb10 100644 --- a/hw/core/machine.c +++ b/hw/core/machine.c @@ -403,6 +403,11 @@ bool machine_usb(MachineState *machine) return machine->usb; } +bool machine_iommu(MachineState *machine) +{ + return machine->iommu; +} + static const TypeInfo machine_info = { .name = TYPE_MACHINE, .parent = TYPE_OBJECT,What does this buy us over a straight current_machine->iommu?
Following QOM guidelines/conventions all object fields are private to machine files only. The *only* ways that they can be exposed are: 1. A wrapper 2. object_property_get... I chose the wrapper because the other variant would be really ugly and should be used only on a generic code. This is the real reason I used this, but pure theoretical speaking using wrappers will give us the opportunity to change machine_iommu implementation without the need to change the call sites. To wrap it up, I just followed previous comments I received on QOM handling. Thanks, Marcel
Same for the other wrapper functions. [...]
[Prev in Thread] | Current Thread | [Next in Thread] |