[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] allow setting static devfn values for pci devic
Re: [Qemu-devel] [PATCH] allow setting static devfn values for pci devices from the command line
Mon, 19 Nov 2007 19:36:28 +0100
On Mon, 2007-11-19 at 18:53 +0200, Izik Eidus wrote:
> Izik Eidus wrote:
> > hi,
> > this patch make it possible to define from the command line a static
> > devfn value for each pci
> > device.
> > it was wrote for addressing a problem that right now qemu devices get
> > their devfn in random way
> > (almost random)
> > the problem with this is that with adding and removing devices some
> > devfn values can be changed
> > for each device.
> > this make (at least) windows unable to understand what happned to your
> > device and mark it
> > in yellow color. (and will want you to reinstall it)
> > in this patch i simply use the device name that was registred with the
> > pci device registration
> > function.
> > in case you have few devices from the same type (same name), it will
> > simply increase each by one
> > so in this case all you have to do is give long enough offset for the
> > devfns from each other.
> > thanks
> ok here is a fix to two issues that i noticed:
> 1.in one place i declared static_devfns[MAX_PCI_DEVICS] and in other
> place: static_devfns[MAX_PCI_DEVICS]
> 2.in one place i did a calculation on a pointer line before i checked if
> it is vaild pointer...
> anyway here it is again and fixed.
It seems that you cannot impose the PCI device numbers mapping, which is
likely to be architecture dependant. What you could however change is
the PCI bus & slot the device is inserted into, the same way you can
choose the PCI slot you put a PCI card into on a real machine. The
architecture could then determine what is the corresponding PCI device
number, given this PCI bus & slot numbers.
For other PCI devices, like PCI bridges or other internal devices, the
PCI slots / devfn are fixed by the architecture. You cannot change them
in any way, then it seems pointless to have an option that would change
the behavior for any of those devices.
The last problem I see is that it seems very ugly to hardcode the device
names the way you did in vl.c. This is even false in most cases, as most
of those devices are only available for a few machines and are not
tunable at all (for example macio or uninorth are only available in some
Apple Mac machines, not even all).
Jocelyn Mayer <address@hidden>