qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH v3] hw/pci/pci_bridge: ensure PCIe slots have only one slot


From: Mark Cave-Ayland
Subject: Re: [PATCH v3] hw/pci/pci_bridge: ensure PCIe slots have only one slot
Date: Wed, 20 Jul 2022 14:21:38 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0

On 20/07/2022 12:00, Roman Kagan wrote:

On Wed, Jul 20, 2022 at 11:44:26AM +0100, Daniel P. Berrangé wrote:
On Wed, Jul 20, 2022 at 01:25:55PM +0300, Roman Kagan wrote:
It's possible to create non-working configurations by attaching a device
to a derivative of PCIe slot (pcie-root-port, ioh3420, etc) and
specifying a slot number other that zero, e.g.:

     -device pcie-root-port,id=s0,... \
     -device virtio-blk-pci,bus=s0,addr=4,...

Make QEMU reject such configurations and only allow addr=0 on the
secondary bus of a PCIe slot.

What do you mean by 'non-working' in this case.  The guest OS boots
OK, but I indeed don't see the device in the guest, but IIUC it was
said that was just because Linux doesn't scan for a non-zero slot.

Right.  I don't remember if it was Linux or firmware or both but indeed
at least Linux guests don't see devices if attached to a PCIe slot at
addr != 0.  (Which is kinda natural for a thing called "slot", isn't it?)

That wouldn't be a broken config from QEMU's POV though, merely a
guest OS limitation ?

Strictly speaking it wouldn't, indeed.  But we've had created such a
configuration (due to a bug in our management layer) and spent
non-negligible time trying to figure out why the attached device didn't
appear in the guest.  So I thought it made sense to reject a
configuration which is known to confuse guests.  Doesn't it?

This does seem a bit odd. What does the output of "info qtree" look like for your non-working configuration?


ATB,

Mark.



reply via email to

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