From: "Andreas Färber" <afaerber@suse.de>
To: Eric Auger <eric.auger@linaro.org>,
Kim Phillips <kim.phillips@linaro.org>
Cc: Peter Maydell <peter.maydell@linaro.org>,
kim.phillips@freescale.com, stuart.yoder@freescale.com,
Markus Armbruster <armbru@redhat.com>,
qemu-devel@nongnu.org, agraf@suse.de, alex.williamson@redhat.com,
Antonios Motakis <a.motakis@virtualopensystems.com>,
kvmarm@lists.cs.columbia.edu,
Christoffer Dall <christoffer.dall@linaro.org>
Subject: Re: [Qemu-devel] [RFC 1/2] hw/arm/virt: add a Calxeda XGMAC device
Date: Wed, 05 Mar 2014 12:25:11 +0100 [thread overview]
Message-ID: <53170997.8060502@suse.de> (raw)
In-Reply-To: <CAJrwac2DTb-mAbhP_FkTUOKtO2pP4w-uoS_R8cUeici-340uhg@mail.gmail.com>
Hi,
Am 05.03.2014 05:27, schrieb Eric Auger:
> Hi Kim,
>
> - Parameter 'driver' expects pluggable device type
> this can be fixed setting dc->cannot_instantiate_with_device_add_yet to
> false in vfio_platform_dev_class_init. You do not get the error anymore.
> However I must aknowledge I have not studies all possible side effects
> of this setting and maybe there is a cleaner way to achieve the same
> result.
If the realize/init function sets up MMIO mappings and IRQs itself
(rather than expecting the code instantiating the device to do so) then
you are free to set that field to false.
In this case that would be vbi->memmap[VIRT_ETHERNET].base in
create_ethernet(), so I have doubts.
Regards,
Andreas
> Then you can add additional properties in dc->props.
> - location of the device in gpa space and impact on RAM size: my
> understanding is that device could sit in another location than the
> hpa's one and you are not compelled to use the same address.
> - we effectively need to work on fdt tree generation for VFIO devices
>
> Best Regards
>
> Eric
>
>
> On 26 February 2014 03:37, Kim Phillips <kim.phillips@linaro.org
> <mailto:kim.phillips@linaro.org>> wrote:
>
> This is a hack and only serves as an example of what needs to be
> done to make the next RFC - add vfio-platform support - work
> for development purposes on a Calxeda Midway system. We don't want
> mach-virt to always create this ethernet device - DO NOT APPLY, etc.
>
> Initial attempts to convince QEMU to create a memory mapped device
> on the command line (e.g., -device vfio-platform,name=fff51000.ethernet)
> would fail with "Parameter 'driver' expects pluggable device type".
> Any guidance as to how to overcome this apparent design limitation
> is welcome.
>
> RAM is reduced from 30 to 1GiB such as to not overlap the xgmac device's
> physical address. Not sure if the 30GiB RAM (or whatever the user sets
> it to with -m) could be set up above 0x1_0000_0000, but there is
> probably
> extra work needed to resolve this type of conflict.
>
> note: vfio-platform interrupt support development may want interrupt
> property data filled; here it's omitted for the time being.
>
> Not-signed-off-by: Kim Phillips <kim.phillips@linaro.org
> <mailto:kim.phillips@linaro.org>>
> ---
> hw/arm/virt.c | 24 +++++++++++++++++++++++-
> 1 file changed, 23 insertions(+), 1 deletion(-)
>
> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
> index 517f2fe..75edf33 100644
> --- a/hw/arm/virt.c
> +++ b/hw/arm/virt.c
> @@ -65,6 +65,7 @@ enum {
> VIRT_GIC_CPU,
> VIRT_UART,
> VIRT_MMIO,
> + VIRT_ETHERNET,
> };
>
> typedef struct MemMapEntry {
> @@ -106,7 +107,8 @@ static const MemMapEntry a15memmap[] = {
> [VIRT_MMIO] = { 0xa000000, 0x200 },
> /* ...repeating for a total of NUM_VIRTIO_TRANSPORTS, each of
> that size */
> /* 0x10000000 .. 0x40000000 reserved for PCI */
> - [VIRT_MEM] = { 0x40000000, 30ULL * 1024 * 1024 * 1024 },
> + [VIRT_MEM] = { 0x40000000, 1ULL * 1024 * 1024 * 1024 },
> + [VIRT_ETHERNET] = { 0xfff51000, 0x1000 },
> };
>
> static const int a15irqmap[] = {
> @@ -291,6 +293,25 @@ static void create_uart(const VirtBoardInfo
> *vbi, qemu_irq *pic)
> g_free(nodename);
> }
>
> +static void create_ethernet(const VirtBoardInfo *vbi, qemu_irq *pic)
> +{
> + char *nodename;
> + hwaddr base = vbi->memmap[VIRT_ETHERNET].base;
> + hwaddr size = vbi->memmap[VIRT_ETHERNET].size;
> + const char compat[] = "calxeda,hb-xgmac";
> +
> + sysbus_create_simple("vfio-platform", base, NULL);
> +
> + nodename = g_strdup_printf("/ethernet@%" PRIx64, base);
> + qemu_fdt_add_subnode(vbi->fdt, nodename);
> +
> + /* Note that we can't use setprop_string because of the
> embedded NUL */
> + qemu_fdt_setprop(vbi->fdt, nodename, "compatible", compat,
> sizeof(compat));
> + qemu_fdt_setprop_sized_cells(vbi->fdt, nodename, "reg", 2,
> base, 2, size);
> +
> + g_free(nodename);
> +}
> +
> static void create_virtio_devices(const VirtBoardInfo *vbi,
> qemu_irq *pic)
> {
> int i;
> @@ -419,6 +440,7 @@ static void machvirt_init(QEMUMachineInitArgs *args)
> }
>
> create_uart(vbi, pic);
> + create_ethernet(vbi, pic);
>
> /* Create mmio transports, so the user can create virtio backends
> * (which will be automatically plugged in to the transports). If
> --
> 1.9.0
>
>
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
next prev parent reply other threads:[~2014-03-05 11:25 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-26 2:37 [Qemu-devel] [RFC 0/2] platform device passthrough Kim Phillips
2014-02-26 2:37 ` [Qemu-devel] [RFC 1/2] hw/arm/virt: add a Calxeda XGMAC device Kim Phillips
2014-03-05 4:27 ` Eric Auger
2014-03-05 11:25 ` Andreas Färber [this message]
2014-03-06 2:27 ` Eric Auger
2014-02-26 2:37 ` [Qemu-devel] [RFC 2/2] hw/misc/vfio: add vfio-platform support Kim Phillips
2014-02-28 18:03 ` Alex Williamson
2014-03-05 0:24 ` Kim Phillips
2014-03-05 1:23 ` Alex Williamson
2014-03-05 11:28 ` Andreas Färber
2014-03-05 11:30 ` Paolo Bonzini
2014-03-05 7:56 ` 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=53170997.8060502@suse.de \
--to=afaerber@suse.de \
--cc=a.motakis@virtualopensystems.com \
--cc=agraf@suse.de \
--cc=alex.williamson@redhat.com \
--cc=armbru@redhat.com \
--cc=christoffer.dall@linaro.org \
--cc=eric.auger@linaro.org \
--cc=kim.phillips@freescale.com \
--cc=kim.phillips@linaro.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=stuart.yoder@freescale.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).