Re: [Qemu-devel] [Xen-devel] [XEN][RFC PATCH 14/15] xl-parsing: Parse the new option device_models
Julien Grall writes ("[Xen-devel] [XEN][RFC PATCH 14/15] xl-parsing: Parse the
new option device_models"):
> For the support of multiple ioreq server, we add a new option "device_models".
> It's an array of device model, for each device model, we need to specify
> which pci, IO range (MMIO, PIO) will be allow.
I don't think this is really a suitable interface. The PCI space in
the guest is controlled by the device models(s) and the user should
surely specify which devices should be provided by which dms, in terms
of devices not in terms of PCI space.
Ian.
Re: [Qemu-devel] [Xen-devel] [XEN][RFC PATCH 14/15] xl-parsing: Parse the new option device_models
On Mon, 2 Apr 2012, Ian Jackson wrote:
> Julien Grall writes ("[Xen-devel] [XEN][RFC PATCH 14/15] xl-parsing: Parse
> the new option device_models"):
> > For the support of multiple ioreq server, we add a new option
> > "device_models".
> > It's an array of device model, for each device model, we need to specify
> > which pci, IO range (MMIO, PIO) will be allow.
>
> I don't think this is really a suitable interface. The PCI space in
> the guest is controlled by the device models(s) and the user should
> surely specify which devices should be provided by which dms, in terms
> of devices not in terms of PCI space.
Julien added a name parameter to select the device, maybe we need
something clearer?
Specifying the PCI address is important, because we have to make sure
the PCI addresses of the devices remain the same in a given VM across
multiple boots.
Thus we could make it optional from the user POV, but in that case we
need a clear, well defined and stable algorithm in xl to figure out a
PCI address from a given config file.
Re: [Qemu-devel] [Xen-devel] [XEN][RFC PATCH 14/15] xl-parsing: Parse the new option device_models
Stefano Stabellini writes ("Re: [Xen-devel] [XEN][RFC PATCH 14/15] xl-parsing:
Parse the new option device_models"):
> On Mon, 2 Apr 2012, Ian Jackson wrote:
> > I don't think this is really a suitable interface. The PCI space in
> > the guest is controlled by the device models(s) and the user should
> > surely specify which devices should be provided by which dms, in terms
> > of devices not in terms of PCI space.
>
> Julien added a name parameter to select the device, maybe we need
> something clearer?
> Specifying the PCI address is important, because we have to make sure
> the PCI addresses of the devices remain the same in a given VM across
> multiple boots.
Are the PCI addresses not assigned in a deterministic fashion by code
in qemu-dm, in this case in the qemu-dm which is emulating the pci
bridge ? If not then that needs to be fixed, surely ?
Ian.
Re: [Qemu-devel] [Xen-devel] [XEN][RFC PATCH 14/15] xl-parsing: Parse the new option device_models
On 04/03/2012 02:31 PM, Ian Jackson wrote:
Stefano Stabellini writes ("Re: [Xen-devel] [XEN][RFC PATCH 14/15] xl-parsing: Parse
the new option device_models"):
On Mon, 2 Apr 2012, Ian Jackson wrote:
I don't think this is really a suitable interface. The PCI space in
the guest is controlled by the device models(s) and the user should
surely specify which devices should be provided by which dms, in terms
of devices not in terms of PCI space.
Julien added a name parameter to select the device, maybe we need
something clearer?
Specifying the PCI address is important, because we have to make sure
the PCI addresses of the devices remain the same in a given VM across
multiple boots.
Are the PCI addresses not assigned in a deterministic fashion by code
in qemu-dm, in this case in the qemu-dm which is emulating the pci
bridge ? If not then that needs to be fixed, surely ?
Indeed but each QEMU emulate a subset of the hardware.
So how QEMU can know the available PCI addresses ?
I think that toolstack must allocate the BDF, otherwise we need to have
communication between each qemu-dm.
Re: [Qemu-devel] [Xen-devel] [XEN][RFC PATCH 14/15] xl-parsing: Parse the new option device_models
Julien Grall writes ("Re: [Xen-devel] [XEN][RFC PATCH 14/15] xl-parsing: Parse
the new option device_models"):
> On 04/03/2012 02:31 PM, Ian Jackson wrote:
> > Are the PCI addresses not assigned in a deterministic fashion by code
> > in qemu-dm, in this case in the qemu-dm which is emulating the pci
> > bridge ? If not then that needs to be fixed, surely ?
>
> Indeed but each QEMU emulate a subset of the hardware.
> So how QEMU can know the available PCI addresses ?
> I think that toolstack must allocate the BDF, otherwise we need to have
> communication between each qemu-dm.
Currently the bdfs are allocated by the single qemu-dm, right ? Why
cannot that functionality stay there, with the pci bridge emulation ?
Ian.
Re: [Qemu-devel] [Xen-devel] [XEN][RFC PATCH 14/15] xl-parsing: Parse the new option device_models
On Tue, 3 Apr 2012, Ian Jackson wrote:
> Julien Grall writes ("Re: [Xen-devel] [XEN][RFC PATCH 14/15] xl-parsing:
> Parse the new option device_models"):
> > On 04/03/2012 02:31 PM, Ian Jackson wrote:
> > > Are the PCI addresses not assigned in a deterministic fashion by code
> > > in qemu-dm, in this case in the qemu-dm which is emulating the pci
> > > bridge ? If not then that needs to be fixed, surely ?
> >
> > Indeed but each QEMU emulate a subset of the hardware.
> > So how QEMU can know the available PCI addresses ?
> > I think that toolstack must allocate the BDF, otherwise we need to have
> > communication between each qemu-dm.
>
> Currently the bdfs are allocated by the single qemu-dm, right ? Why
> cannot that functionality stay there, with the pci bridge emulation ?
Because the allocation of most BDFs in QEMU is done ad-hoc in a first
come first served basis. If the first QEMU is not going to emulate these
devices then it is not going to allocate the BDF for them either.
Re: [Qemu-devel] [Xen-devel] [XEN][RFC PATCH 14/15] xl-parsing: Parse the new option device_models
Stefano Stabellini writes ("Re: [Xen-devel] [XEN][RFC PATCH 14/15] xl-parsing:
Parse the new option device_models"):
> On Tue, 3 Apr 2012, Ian Jackson wrote:
> > Currently the bdfs are allocated by the single qemu-dm, right ? Why
> > cannot that functionality stay there, with the pci bridge emulation ?
>
> Because the allocation of most BDFs in QEMU is done ad-hoc in a first
> come first served basis. If the first QEMU is not going to emulate these
> devices then it is not going to allocate the BDF for them either.
Do we want the bdf allocation to be stable when switching between the
combined and disaggregated qemu-dms ? If we do then it still needs to
be done by that qemu-dm using the same algorithm, presumably with
additional ipc.
If we don't then it would be ok for the bdfs to be allocated by new
code in the toolstack somewhere, eg libxl, but it still shouldn't be
up to the user to configure.
Ian.
