qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Alexey Kardashevskiy <aik@ozlabs.ru>
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
Subject: Re: [Qemu-devel] pci: single device at function != 0
Date: Wed, 20 Nov 2013 19:04:50 +1100	[thread overview]
Message-ID: <1384934690.26969.87.camel@pasglop> (raw)
In-Reply-To: <528C6725.2070605@ozlabs.ru>

On Wed, 2013-11-20 at 18:39 +1100, Alexey Kardashevskiy wrote:
> Hi!
> 
> It turned out that it is possible to start QEMU with a single PCI device
> placed at 0:0:1.1. I.e. function#1 and there is no function#0. The existing
> QEMU only fails if there is function#0 AND the multifunction bit is not set
> which is not the case.
> 
> Is it supposed to work anywhere (x86 may be)?

Not on normal x86 nor any "real" PCI ... but it does exist in some PAPR
cases, usually old stuff, where pHyp would expose individual functions
to guests.
 
> In our case SLOF does not scan other functions if there is nothing at
> function#0. And the linux kernel does the same thing - it scans other
> functions only if sees "multifunction" on function#0.
> 
> But I cannot see anywhere in the PCI spec that this configuration is
> illegal and must not work. Normally "pseries" guest does not scan PCI and
> uses what it gets via the device tree and if we put there devices at
> 0:0:1.1, it is expected to see the device and work (but not sure).

It is not really a legal configuration

> So - is it a SLOF bug? Or QEMU just does not have right place before
> starting the machine to verify that some devices do not have a PCI function
> at 0 and print a warning that they won't be detected by the guest? Thanks.
> 
> 
> This is the command line example:
> 
> ./qemu-system-ppc64 \
>  -trace "events=qemu_trace_events" \
>  -L "qemu-ppc64-bios/" \
>  -nographic \
>  -vga "none" \
>  -device \
>  virtio-blk-pci,scsi=off,bus=pci,addr=1.1,drive=drive-virtio-disk53,id=virtio-disk53 \
>  -drive \
>  file=virtimg/test1,if=none,id=drive-virtio-disk53,format=qcow2,cache=none \
>  -S \
>  -m "2048" \
>  -machine "pseries" \
>  -enable-kvm \
>  -kernel "vml312-probe-pci" \
>  -initrd "1.cpio"
> 
> 
> 

      reply	other threads:[~2013-11-20  8:05 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-20  7:39 [Qemu-devel] pci: single device at function != 0 Alexey Kardashevskiy
2013-11-20  8:04 ` Benjamin Herrenschmidt [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1384934690.26969.87.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=aik@ozlabs.ru \
    --cc=nikunj@linux.vnet.ibm.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).