From: Frank Blaschka <blaschka@linux.vnet.ibm.com>
To: Alexander Graf <agraf@suse.de>
Cc: cornelia.huck@de.ibm.com, borntraeger@de.ibm.com, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH RFC 1/1] s390x/pci: Extend pci representation by new zpci device
Date: Thu, 26 Feb 2015 16:27:01 +0100 [thread overview]
Message-ID: <20150226152701.GA31166@tuxmaker.boeblingen.de.ibm.com> (raw)
In-Reply-To: <54EF3013.8020608@suse.de>
On Thu, Feb 26, 2015 at 03:39:15PM +0100, Alexander Graf wrote:
>
>
> On 26.02.15 12:59, Frank Blaschka wrote:
> > This patch extends the current s390 pci implementation to
> > provide more flexibility in configuration of s390 specific
> > device handling. For this we had to introduce a new facility
> > (and bus) to hold devices representing information actually
> > provided by s390 firmware and I/O configuration.
> >
> > On s390 the physical structure of the pci system (bridge, bus, slot)
> > in not shown to the OS. For this the pci bridge and bus created
> > in qemu can also not be shown to the guest. The new zpci device class
> > represents this abstract view on the bare pci function and allows to
> > provide s390 specific configuration attributes for it.
> >
> > Sample qemu configuration:
> > -device e1000,id=zpci1
> > -device ne2k_pci,id=zpci2
> > -device zpci,fid=2,uid=1248,pci_id=zpci1
> > -device zpci,fid=17,uid=2244,pci_id=zpci2
> >
> > A zpci device references the corresponding PCI device via device id.
> > The new design allows to define multiple host bridges and support more
> > pci devices.
>
> Isn't this reverse? Shouldn't it rather be
>
> -device zpci,...,id=zpci1
> -device e1000,bus=zpci1.0
>
> with a limit on each virtual zpci bus to only support one device?
Do you mean something like having multiple host bridges (providing a pci bus
each) and limit the bus to just one device?
-device s390-pcihost,fid=16,uid=1234
-device s390-pcihost,fid=17,uid=5678
-device e1000,bus=pci.0
-device ne2k_pci,bus=pci.1
We also discussed this option but we don't like the idea to put attributes
belong to the pci device to the host bridge.
>
>
> Alex
>
next prev parent reply other threads:[~2015-02-26 15:27 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-26 11:59 [Qemu-devel] [PATCH RFC 0/1] Extend s390 pci representation in qemu Frank Blaschka
2015-02-26 11:59 ` [Qemu-devel] [PATCH RFC 1/1] s390x/pci: Extend pci representation by new zpci device Frank Blaschka
2015-02-26 14:39 ` Alexander Graf
2015-02-26 15:27 ` Frank Blaschka [this message]
2015-02-26 15:34 ` Alexander Graf
2015-03-03 8:06 ` Frank Blaschka
2015-03-03 9:33 ` Alexander Graf
2015-03-03 13:25 ` Frank Blaschka
2015-03-03 20:38 ` Alexander Graf
2015-03-04 13:44 ` Frank Blaschka
2015-03-04 14:49 ` Alexander Graf
2015-03-04 15:07 ` Frank Blaschka
2015-03-04 15:25 ` Alexander Graf
2015-03-04 15:58 ` Frank Blaschka
2015-03-06 10:34 ` Frank Blaschka
2015-03-06 10:49 ` Alexander Graf
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=20150226152701.GA31166@tuxmaker.boeblingen.de.ibm.com \
--to=blaschka@linux.vnet.ibm.com \
--cc=agraf@suse.de \
--cc=borntraeger@de.ibm.com \
--cc=cornelia.huck@de.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).