From: Alexander Graf <agraf@suse.de>
To: Eric Auger <eric.auger@linaro.org>,
eric.auger@st.com, christoffer.dall@linaro.org,
qemu-devel@nongnu.org, pbonzini@redhat.com,
kim.phillips@freescale.com, a.rigo@virtualopensystems.com,
manish.jaggi@caviumnetworks.com, joel.schopp@amd.com
Cc: peter.maydell@linaro.org, patches@linaro.org,
will.deacon@arm.com, stuart.yoder@freescale.com,
Bharat.Bhushan@freescale.com, alex.williamson@redhat.com,
a.motakis@virtualopensystems.com, kvmarm@lists.cs.columbia.edu
Subject: Re: [Qemu-devel] [PATCH v7 12/16] hw/arm/sysbus-fdt: enable vfio-calxeda-xgmac dynamic instantiation
Date: Wed, 05 Nov 2014 23:23:07 +0100 [thread overview]
Message-ID: <545AA34B.4050303@suse.de> (raw)
In-Reply-To: <545A18BF.3050001@linaro.org>
On 05.11.14 13:31, Eric Auger wrote:
> On 11/05/2014 11:59 AM, Alexander Graf wrote:
>>
>>
>> On 31.10.14 15:05, Eric Auger wrote:
>>> vfio-calxeda-xgmac now can be instantiated using the -device option.
>>> The node creation function generates a very basic dt node composed
>>> of the compat, reg and interrupts properties
>>>
>>> Signed-off-by: Eric Auger <eric.auger@linaro.org>
>>>
>>> ---
>>>
>>> v6 -> v7:
>>> - compat string re-formatting removed since compat string is not exposed
>>> anymore as a user option
>>> - VFIO IRQ kick-off removed from sysbus-fdt and moved to VFIO platform
>>> device
>>> ---
>>> hw/arm/sysbus-fdt.c | 88 +++++++++++++++++++++++++++++++++++++++++++++++++++++
>>> 1 file changed, 88 insertions(+)
>>>
>>> diff --git a/hw/arm/sysbus-fdt.c b/hw/arm/sysbus-fdt.c
>>> index d5476f1..f8b310b 100644
>>> --- a/hw/arm/sysbus-fdt.c
>>> +++ b/hw/arm/sysbus-fdt.c
>>> @@ -27,6 +27,8 @@
>>> #include "hw/platform-bus.h"
>>> #include "sysemu/sysemu.h"
>>> #include "hw/platform-bus.h"
>>> +#include "hw/vfio/vfio-platform.h"
>>> +#include "hw/vfio/vfio-calxeda-xgmac.h"
>>>
>>> /*
>>> * internal struct that contains the information to create dynamic
>>> @@ -54,8 +56,11 @@ typedef struct NodeCreationPair {
>>> int (*add_fdt_node_fn)(SysBusDevice *sbdev, void *opaque);
>>> } NodeCreationPair;
>>>
>>> +static int add_basic_vfio_fdt_node(SysBusDevice *sbdev, void *opaque);
>>> +
>>> /* list of supported dynamic sysbus devices */
>>> NodeCreationPair add_fdt_node_functions[] = {
>>> + {TYPE_VFIO_CALXEDA_XGMAC, add_basic_vfio_fdt_node},
>>> {"", NULL}, /*last element*/
>>> };
>>
>> Can you maybe place the list somewhere smartly to make sure we don't
>> need forward declarations? Either put it in between the "generic" and
>> "device specific" code or at the end of the file with a single forward
>> declaration for the array?
>
> sure
>>
>>>
>>> @@ -86,6 +91,89 @@ static int add_fdt_node(SysBusDevice *sbdev, void *opaque)
>>> }
>>>
>>> /**
>>> + * add_basic_vfio_fdt_node - generates the most basic node for a VFIO node
>>> + *
>>> + * set properties are:
>>> + * - compatible string
>>> + * - regs
>>> + * - interrupts
>>> + */
>>> +static int add_basic_vfio_fdt_node(SysBusDevice *sbdev, void *opaque)
>>> +{
>>> + PlatformBusFdtData *data = opaque;
>>> + PlatformBusDevice *pbus = data->pbus;
>>> + void *fdt = data->fdt;
>>> + const char *parent_node = data->pbus_node_name;
>>> + int compat_str_len;
>>> + char *nodename;
>>> + int i, ret;
>>> + uint32_t *irq_attr;
>>> + uint64_t *reg_attr;
>>> + uint64_t mmio_base;
>>> + uint64_t irq_number;
>>> + VFIOPlatformDevice *vdev = VFIO_PLATFORM_DEVICE(sbdev);
>>> + VFIODevice *vbasedev = &vdev->vbasedev;
>>> + Object *obj = OBJECT(sbdev);
>>> +
>>> + mmio_base = object_property_get_int(obj, "mmio[0]", NULL);
>>> +
>>> + nodename = g_strdup_printf("%s/%s@%" PRIx64, parent_node,
>>> + vbasedev->name,
>>> + mmio_base);
>>> +
>>> + qemu_fdt_add_subnode(fdt, nodename);
>>> +
>>> + compat_str_len = strlen(vdev->compat) + 1;
>>> + qemu_fdt_setprop(fdt, nodename, "compatible",
>>> + vdev->compat, compat_str_len);
>>
>> What if there are multiple compatibles?
> My purpose here was absolutely not to come back again on a proposal
> where we could have a generic node creation. I understand that it is not
> realistic. I rather tried to put some common property creation in this
> function but you're right even the interrupt prop depend on the device.
>
> About your question, I think the specialized VFIO device would set its
> compat string including the various substrings. This was done in the
> past for PL330 which required arm,pl330;arm,primecell.
>
>>
>>> +
>>> + reg_attr = g_new(uint64_t, vbasedev->num_regions*4);
>>> +
>>> + for (i = 0; i < vbasedev->num_regions; i++) {
>>> + mmio_base = platform_bus_get_mmio_addr(pbus, sbdev, i);
>>> + reg_attr[4*i] = 1;
>>
>> What is the 1 here?
> address-cells? since the bus is < 4GB, 1 32b reg is required to specify
> the base address. But since you put #size-cells already in the parent
> node maybe I can remove it.
I'm confused. Shouldn't the reg look like [ <addr> <size> ... ]?
http://www.devicetree.org/Device_Tree_Usage#Memory_Mapped_Devices
The number of cells is defined separately via #address-cells or #size-cells.
>
>>
>>> + reg_attr[4*i+1] = mmio_base;
>>> + reg_attr[4*i+2] = 1;
>>
>> and here?
> size-cells for this reg. same remark as above
Alex
next prev parent reply other threads:[~2014-11-05 22:23 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-31 14:05 [Qemu-devel] [PATCH v7 00/16] KVM platform device passthrough Eric Auger
2014-10-31 14:05 ` [Qemu-devel] [PATCH v7 01/16] vfio: move hw/misc/vfio.c to hw/vfio/pci.c Move vfio.h into include/hw/vfio Eric Auger
2014-10-31 14:05 ` [Qemu-devel] [PATCH v7 02/16] hw/vfio/pci: Rename VFIODevice into VFIOPCIDevice Eric Auger
2014-10-31 14:05 ` [Qemu-devel] [PATCH v7 03/16] hw/vfio/pci: introduce VFIODevice Eric Auger
2014-11-05 17:35 ` Alex Williamson
2014-11-06 8:38 ` Eric Auger
2014-10-31 14:05 ` [Qemu-devel] [PATCH v7 04/16] hw/vfio/pci: Introduce VFIORegion Eric Auger
2014-10-31 14:05 ` [Qemu-devel] [PATCH v7 05/16] hw/vfio/pci: split vfio_get_device Eric Auger
2014-10-31 14:05 ` [Qemu-devel] [PATCH v7 06/16] hw/vfio/pci: rename group_list into vfio_group_list Eric Auger
2014-10-31 14:05 ` [Qemu-devel] [PATCH v7 07/16] hw/vfio/pci: use name field in format strings Eric Auger
2014-10-31 14:05 ` [Qemu-devel] [PATCH v7 08/16] hw/vfio: create common module Eric Auger
2014-10-31 14:05 ` [Qemu-devel] [PATCH v7 09/16] hw/vfio/platform: add vfio-platform support Eric Auger
2014-11-05 10:29 ` Alexander Graf
2014-11-05 12:03 ` Eric Auger
2014-11-05 13:05 ` Alexander Graf
2014-11-26 9:45 ` Eric Auger
2014-11-26 10:24 ` Alexander Graf
2014-11-26 10:48 ` Eric Auger
2014-11-26 11:20 ` Alexander Graf
2014-11-26 14:46 ` Eric Auger
2014-11-27 14:05 ` Eric Auger
2014-11-27 14:35 ` Alexander Graf
2014-11-27 15:14 ` Eric Auger
2014-11-27 15:28 ` Alexander Graf
2014-11-27 15:55 ` Alexander Graf
2014-11-27 17:13 ` Eric Auger
2014-11-27 17:24 ` Alexander Graf
2014-11-27 17:34 ` Eric Auger
2014-11-27 17:51 ` Alexander Graf
2014-11-27 17:54 ` Eric Auger
2014-10-31 14:05 ` [Qemu-devel] [PATCH v7 10/16] hw/vfio: calxeda xgmac device Eric Auger
2014-11-05 10:26 ` Alexander Graf
2014-10-31 14:05 ` [Qemu-devel] [PATCH v7 11/16] hw/arm/virt: add support for VFIO devices Eric Auger
2014-10-31 14:05 ` [Qemu-devel] [PATCH v7 12/16] hw/arm/sysbus-fdt: enable vfio-calxeda-xgmac dynamic instantiation Eric Auger
2014-11-05 10:59 ` Alexander Graf
2014-11-05 12:31 ` Eric Auger
2014-11-05 22:23 ` Alexander Graf [this message]
2014-11-06 8:57 ` Eric Auger
2014-11-06 12:34 ` Alexander Graf
2014-10-31 14:05 ` [Qemu-devel] [PATCH v7 13/16] hw/vfio/platform: Add irqfd support Eric Auger
2014-10-31 14:05 ` [Qemu-devel] [PATCH v7 14/16] linux-headers: Update KVM headers from linux-next tag ToBeFilled Eric Auger
2014-10-31 14:05 ` [Qemu-devel] [PATCH v7 15/16] hw/vfio/common: vfio_kvm_device_fd moved in the common header Eric Auger
2014-10-31 14:05 ` [Qemu-devel] [PATCH v7 16/16] hw/vfio/platform: add forwarded irq support Eric Auger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=545AA34B.4050303@suse.de \
--to=agraf@suse.de \
--cc=Bharat.Bhushan@freescale.com \
--cc=a.motakis@virtualopensystems.com \
--cc=a.rigo@virtualopensystems.com \
--cc=alex.williamson@redhat.com \
--cc=christoffer.dall@linaro.org \
--cc=eric.auger@linaro.org \
--cc=eric.auger@st.com \
--cc=joel.schopp@amd.com \
--cc=kim.phillips@freescale.com \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=manish.jaggi@caviumnetworks.com \
--cc=patches@linaro.org \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=stuart.yoder@freescale.com \
--cc=will.deacon@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).