[Top][All Lists]
[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: |
Markus Armbruster |
Subject: |
Re: [Qemu-devel] Re: May I use -device in qemu-system command to attach to PCIe bus? |
Date: |
Fri, 29 Oct 2010 11:54:27 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) |
[Note cc: Michael & Gerd]
Isaku Yamahata <address@hidden> writes:
> 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.
Guest-assigned addresses need not be stable and predictable. Using them
for QEMU device configuration feels wrong to me.
Is there a way to name a PCI bus that is independent of guest software?
>> 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.
Got it.
> I suppose that -device/device_add uses qdev path, not pci address,
> so it would be okay.
Yes, except qdev paths are a bit of a mess right now. Separate problem.
> pci_add or -net nic wouldn't work. (or only works with bus=0)