qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC v4 PATCH 09/49] multi-process: setup PCI host bridge for remote


From: Stefan Hajnoczi
Subject: Re: [RFC v4 PATCH 09/49] multi-process: setup PCI host bridge for remote device
Date: Thu, 21 Nov 2019 10:37:52 +0000
User-agent: Mutt/1.12.1 (2019-06-15)

On Mon, Nov 18, 2019 at 10:25:59AM -0500, Jag Raman wrote:
> On 11/13/2019 11:07 AM, Stefan Hajnoczi wrote:
> > On Thu, Oct 24, 2019 at 05:08:50AM -0400, Jagannathan Raman wrote:
> > > +static void remote_host_realize(DeviceState *dev, Error **errp)
> > > +{
> > > +    PCIHostState *pci = PCI_HOST_BRIDGE(dev);
> > > +    RemPCIHost *s = REMOTE_HOST_DEVICE(dev);
> > > +
> > > +    /*
> > > +     * TODO: the name of the bus would be provided by QEMU. Use
> > > +     * "pcie.0" for now.
> > > +     */
> > > +    pci->bus = pci_root_bus_new(DEVICE(s), "pcie.0",
> > > +                                s->mr_pci_mem, s->mr_sys_io,
> > > +                                0, TYPE_PCIE_BUS);
> > 
> > The PCI bus name could be a property and then whatever instantiates
> > RemPCIHost could set it.
> > 
> > Machine types usually hardcode the name because they assume there is
> > only one machine instance.  In the case of mpqemu this is an okay
> > starting point, but maybe multiple busses will become necessary if the
> > device emulation process handles multiple device instances - especially
> > if they are served to multiple guests like in a software-defined network
> > switch use case.
> 
> Are you referring to a case where a single remote process will emulate
> devices from multiple guests?
> 
> We haven't thought about that application. But we will certainly add the
> ability to specify the name of the bus as a parameter.

Sooner or later someone will want to run multiple devices in one device
emulation process, but it's not critical to support it in this patch
series.  I think it can be implemented later without breaking any stable
interfaces.

Stefan

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]