qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Re: May I use -device in qemu-system command to attach


From: Isaku Yamahata
Subject: Re: [Qemu-devel] Re: May I use -device in qemu-system command to attach to PCIe bus?
Date: Fri, 29 Oct 2010 17:40:36 +0900
User-agent: Mutt/1.5.19 (2009-01-05)

On Fri, Oct 29, 2010 at 10:02:47AM +0200, Markus Armbruster wrote:
> Isaku Yamahata <address@hidden> writes:
> 
> > On Thu, Oct 28, 2010 at 03:37:27AM -0700, Wei Xu wrote:
> >> Isaku,
> >> 
> >> To make things clear, let me rephrase the problem. With q35/vPCIe, in VMM
> >> monitor, we can do hotplug like:
> >>  pci_add auto|<bus:dev> nic|storage
> >> to hotplug a device to PCIe/PCI bus.
> >> 
> >> But we have two problems  here:
> >> (1) command line for example, "-net nic,addr=<bus:dev>" always failed
> >> because it cannot find the bus.
> >> (2) If "pci_add auto" in monitor or no "addr=<bus:dev" in command line, the
> >> device will be attached to PCI bus, in stead of PCIe ports
> >> 
> >> I solved the first problem. The root cause is pcie_root_write_config (which
> >> init SECONDARY_BUS config) happened after pci_nic_init. The latter use
> >> pci_find_bus to find the parent bus but failed because config space for
> >> secondary bus still not initialized.
> >
> > Okay, now the issue is clear to me.
> > When I tried to clean up pci bridge code, I included the similar lines
> > in bridge initialization function.
> > But Michael complained about it, so I dropped the lines for merge.
> >
> > I think there are two ways to address it.
> > - initialize secondary/subordinate bus register by qemu
> >   i.e. something like the patch below.
> >
> > - use qdev device path
> >   i.e. qbus_find() instead of pci_find_bus().
> >   I don't know if the corresponding command line option already exists or 
> > not.
> >
> > My preference is the former, but discussion is necessary to get consensus.
> > My plan was to raise the issue when I address pv pci bus numbering issue.
> > I've expected that other developers wouldn't think the issue important
> > because multiple pci bus can't be used easily right now.
> 
> I'm afraid I'm missing context here.  Could you restate the problem?

Wei, please correct/clarify me if I'm wrong.

The issues is that pci address, (segment, bus, dev, fn), doesn't always
work as an argument to qemu command line or qemu monitor because
pci bus numbering is done by guest BIOS/OS.
In flat pci bus case, i.e. there is a single pci bus of bus=0,
fortunately it works.
But if there are multiple pci buses, (segment, bus, dev, fn)
doesn't work as expected until guest bios/os numbers pci buses.
For example if pci bus address with non-0 bus number is passed as
qemu command line option in order to add pci device, qemu fails to
find the pci bus.


> New devices and buses need to work with -device / device_add.  pci_add
> and -net nic are for backwards compatibility.  Folks used to them may
> appreciate you making them work for PCIe.  Longer term, they should
> either go away or become syntactic sugar.

The issue is caused not by pcie, but by multiple pci buses.
I suppose that -device/device_add uses qdev path, not pci address,
so it would be okay.
pci_add or -net nic wouldn't work. (or only works with bus=0)
-- 
yamahata



reply via email to

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