Re: [Qemu-devel] [PATCH 1/2] hw: cannot_instantiate_with_device_add_yet due to pointer props

[Peter Crosthwaite]

Hi Andreas,

On Fri, Jan 10, 2014 at 7:10 PM, Andreas Färber <address@hidden> 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
>