All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
To: "Andreas Färber" <afaerber@suse.de>,
	"Michal Simek" <michal.simek@xilinx.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Marcel Apfelbaum <marcel.a@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	QEMU Developers <qemu-devel@nongnu.org>,
	Fabien Chouteau <chouteau@adacore.com>,
	Markus Armbruster <armbru@redhat.com>,
	Blue Swirl <blauwirbel@gmail.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	Anthony Liguori <aliguori@amazon.com>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>
Subject: Re: [Qemu-devel] [PATCH 1/2] hw: cannot_instantiate_with_device_add_yet due to pointer props
Date: Fri, 10 Jan 2014 20:35:03 +1000	[thread overview]
Message-ID: <CAEgOgz4hjKgK78hnaygrYhJEQxmD1LAAiS0h_Wc=LXMNA51R6g@mail.gmail.com> (raw)
In-Reply-To: <52CFB922.7080101@suse.de>

Hi Andreas,

On Fri, Jan 10, 2014 at 7:10 PM, Andreas Färber <afaerber@suse.de> wrote:
> Peter,
>
> Am 07.01.2014 14:05, schrieb Peter Crosthwaite:
>> If you bring FPGAs into the game, SYSBUS itself is ultimately
>> pluggable. All sysbus devices under the sun are therefore legitimately
>> "pluggable" in target-microblaze.
>
> You'll have to expand on this statement. :) From what I understand from
> documentation for Zynq based boards, the SoC-integrated FPGA is
> initialized with a big binary(?)

Yes a "bitstream" for short.

 > blob from U-Boot firmware.

So u-boot isn't firmware. u-boot (if you use it) is stored on off-chip
and loaded by earlier boot stages.

> You then
> need to supply a flat device tree to Linux, specifying what devices are
> exposed by SoC/FPGA, and from then on there is no hot-plug of such
> platform devices any more.

That's only a limitation of current-gen Linux. I'm not sure what the
state of the kernel WRT to devcfg support is TBH. Michal may know
more.

> So unless Xilinx is capable of parsing their
> FPGA logic blob back into individual QEMU devices,

No not possible , the bitstream is not self-identifying.

 it seems to me you
> are talking about an initial set of devices rather than device_add'ing
> devices after Linux is running.

But it is possible with some driver patches. The devcfg peripheral
(the FPGA bitstream loader) is just another peripheral in the ZYNQ
SoC. Any guest can program it at anytime. If we just focus on the
hardware capability, zynq is very hotpluggable.

> To cope with that requirement, devices
> should be made instantiatable from command line or config file (I think
> we all agree on that goal), but it does not make SysBus hotpluggable.
>
> Or am I missing something? Is it possible to alter FPGA configuration
> from inside arm Linux and, if so, how does Linux cope with that?
>
> In the case of the existing MicroBlaze machine(s), I assume that it
> represents an FPGA board that has been pre-programmed with the softcore
> processor code.

So I think earlier in this thread we started making the distinction
between "pluggable" and "hot pluggable". Zynq, based on the guests
ability to add peripherals straight onto the system bus is definitely
hot-pugging.

But even with MB, the ability to easily come up with a new microblaze
designs with extra stuff on the system bus to me satisfies some good
definitions of "pluggable". It's advantageous to therefore be able to
dynamically construct MB machines rather than the embedded status quo
of fixed machine models. TBH we've been doing it for a long time now
out of tree with the -M fdt_generic machine models (constructs the
full machine from the -dtb argument).

I would generally assume any such device-adding mechanisms whether
they be device-tree or command line or whatever to back onto the
pluggability frameworks we are talking about here.

> So reprogramming the FPGA at runtime would mean changing
> the processor that is executing the code changing the processor...
> sounds dangerous on hardware and thus hopefully not something we need to
> worry about for now, do we?
>

It is theoretically possible as FPGAs can be partially reconfigured.
That said, its neither well used or supported and its not something I
can see myself worrying about anytime soon.

> Regards,
> Andreas
>
> P.S. Note that I had been arguing that if a SysBusDevice does not have a
> mappable MMIO region or IRQs then we wouldn't need to set
> cannot_instantiate_... The pending series does it for all SysBusDevices
> though, so if you do have such exceptional devices, we can override
> dc->cannot_instantiate_... in class_init.
>

It's hard to identify all such exceptions. For example, Xilinx has a
soft EHCI solution that would be nice to emulate with just a

-device sysbus-ehci,interrupt-parent=/path/to/intc,bus=/path/to/bus,address=0xf00,...

There is advantage to making it work for all sysbus or at least MB
peripherals and standard HCI peripherals.

Regards,
Peter

> --
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
>

  reply	other threads:[~2014-01-10 10:35 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-29  9:43 [Qemu-devel] [PATCH 0/2] Pointer properties and device_add armbru
2013-11-29  9:43 ` [Qemu-devel] [PATCH 1/2] hw: cannot_instantiate_with_device_add_yet due to pointer props armbru
2013-11-29 10:23   ` Edgar E. Iglesias
2013-12-15 20:55   ` Andreas Färber
2013-12-15 21:10     ` Peter Maydell
2013-12-16  8:48       ` Markus Armbruster
2013-12-16  9:33         ` Peter Maydell
2013-12-16 11:17           ` Markus Armbruster
2014-01-07 12:33           ` Andreas Färber
2014-01-07 12:43             ` Peter Maydell
2014-01-07 13:04               ` Andreas Färber
2014-01-07 13:05               ` Peter Crosthwaite
2014-01-10  9:10                 ` Andreas Färber
2014-01-10 10:35                   ` Peter Crosthwaite [this message]
2014-01-07 14:08               ` Markus Armbruster
2014-01-07 16:50               ` Paolo Bonzini
2013-11-29  9:43 ` [Qemu-devel] [PATCH 2/2] qdev: Document that pointer properties kill device_add armbru
2013-12-01 13:13 ` [Qemu-devel] [PATCH 0/2] Pointer properties and device_add Marcel Apfelbaum
2013-12-01 15:14   ` Andreas Färber
2013-12-02  7:30     ` Markus Armbruster
2013-12-02  9:05       ` Marcel Apfelbaum
2013-12-02  8:52     ` Marcel Apfelbaum
2013-12-15 20:51       ` Andreas Färber
2013-12-16  8:26         ` Marcel Apfelbaum
2013-12-15 21:02 ` Andreas Färber
2013-12-16  8:52   ` Markus Armbruster

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='CAEgOgz4hjKgK78hnaygrYhJEQxmD1LAAiS0h_Wc=LXMNA51R6g@mail.gmail.com' \
    --to=peter.crosthwaite@xilinx.com \
    --cc=afaerber@suse.de \
    --cc=aliguori@amazon.com \
    --cc=armbru@redhat.com \
    --cc=blauwirbel@gmail.com \
    --cc=chouteau@adacore.com \
    --cc=edgar.iglesias@gmail.com \
    --cc=kraxel@redhat.com \
    --cc=marcel.a@redhat.com \
    --cc=michal.simek@xilinx.com \
    --cc=mst@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.