From: "Richard W.M. Jones" <rjones@redhat.com>
To: Andrea Bolognani <abologna@redhat.com>
Cc: Alistair <alistair23@gmail.com>,
Alistair Francis <Alistair.Francis@wdc.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"mjc@sifive.com" <mjc@sifive.com>,
"palmer@sifive.com" <palmer@sifive.com>,
"stephen@eideticom.com" <stephen@eideticom.com>
Subject: Re: [Qemu-devel] [PATCH v5 0/5] Connect a PCIe host and graphics support to RISC-V
Date: Thu, 11 Oct 2018 08:55:44 +0100 [thread overview]
Message-ID: <20181011075544.GR27120@redhat.com> (raw)
In-Reply-To: <7d54ec114745b00b82601875416ccfe6a5f9fe6f.camel@redhat.com>
On Thu, Oct 11, 2018 at 07:59:59AM +0200, Andrea Bolognani wrote:
> On Wed, 2018-10-10 at 10:57 -0700, Alistair wrote:
> > On 10/10/2018 05:26 AM, Andrea Bolognani wrote:
> > > * what should libvirt look for to figure out whether or not a RISC-V
> > > guest will have PCI support? For aarch64 we look for the presence
> > > of the 'gpex-pcihost' device, but of course that won't work for
> > > RISC-V so we need something else;
> >
> > I'm not sure what you mean here. Why can we not do the same thing with
> > RISC-V?
>
> The gpex-pcihost device was introduced at the same time as
> aarch64/virt gained PCI support, so we can probe the binary[1] and,
> if the device is present, we know that aarch64/virt guests will be
> able to use PCI. We cannot do the same for RISC-V for obvious
> reasons: the device is already there :)
>
> Is there any RISC-V device / property that was introduced along
> with PCI support and we can use as a witness?
Can we ignore non-PCIe guests? virtio-mmio should die.
Also if we ever get to the stage where (real) RISC-V servers are
shipping that don't have PCIe, then I'm afraid I will have lost a
critical battle :-( Non-PCI might be OK for tiny embedded stuff, but
for proper machines - real and virtual - we should require PCIe.
> > > * I have succesfully started a RISC-V guest with virtio-pci devices
> > > attached but, while they show up in 'info qtree' and friends, the
> > > guest OS itself doesn't seem to recognize any of them - not even
> > > pcie.0! I'm using the guest images listed at [1] and following the
> > > corresponding instructions, but I think the BBL build (config at
> > > [2]) is missing some feature... Any ideas what we would need to
> > > add there?
> >
> > I use this monolithic config:
> > https://github.com/alistair23/meta-riscv/blob/7a950aa705b439b5ec19bb6f094930888335ba7b/recipes-kernel/linux/files/freedom-u540/defconfig
> >
> > It has way too much enabled, but I think if you copy the PCIe part that
> > should be enough.
>
> Looks like there's quite a few CONFIG*PCI* options we're missing!
>
> Rich, can you try incorporating those and kicking off a BBL build?
> If I remember correctly you might also have to backport a commit or
> two to make some of the options available on RISC-V, but it should
> be very feasible.
I'll have a look.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
next prev parent reply other threads:[~2018-10-11 7:55 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-04 20:06 [Qemu-devel] [PATCH v5 0/5] Connect a PCIe host and graphics support to RISC-V Alistair Francis
2018-10-04 20:06 ` [Qemu-devel] [PATCH v5 1/5] hw/riscv/virt: Increase the number of interrupts Alistair Francis
2018-10-04 20:06 ` [Qemu-devel] [PATCH v5 2/5] hw/riscv/virt: Connect the gpex PCIe Alistair Francis
2018-10-25 18:47 ` Peter Maydell
2018-10-30 21:39 ` Alistair Francis
2018-10-04 20:06 ` [Qemu-devel] [PATCH v5 3/5] riscv: Enable VGA and PCIE_VGA Alistair Francis
2018-10-04 20:06 ` [Qemu-devel] [PATCH v5 4/5] hw/riscv/sifive_u: Connect the Xilinx PCIe Alistair Francis
2018-10-04 20:06 ` [Qemu-devel] [PATCH v5 5/5] hw/riscv/virt: Connect a VirtIO net PCIe device Alistair Francis
2018-10-10 12:26 ` [Qemu-devel] [PATCH v5 0/5] Connect a PCIe host and graphics support to RISC-V Andrea Bolognani
2018-10-10 13:11 ` Stephen Bates
2018-10-10 13:43 ` Andrea Bolognani
2018-10-10 17:24 ` Stephen Bates
2018-10-10 17:32 ` Stephen Bates
2018-10-10 18:01 ` Alistair
2018-10-10 18:47 ` Stephen Bates
2018-10-10 19:53 ` Alistair
2018-10-11 5:45 ` Andrea Bolognani
2018-10-10 19:01 ` Stephen Bates
2018-10-10 19:55 ` Alistair
2018-10-10 17:57 ` Alistair
2018-10-11 5:59 ` Andrea Bolognani
2018-10-11 7:55 ` Richard W.M. Jones [this message]
2018-10-11 12:00 ` Peter Maydell
2018-10-11 8:01 ` Richard W.M. Jones
2018-10-11 11:45 ` Richard W.M. Jones
2018-10-11 12:15 ` Andrea Bolognani
2018-10-11 12:25 ` Stephen Bates
2018-10-11 17:40 ` Alistair Francis
2018-10-12 13:46 ` Andrea Bolognani
2018-10-12 16:12 ` Alistair Francis
2018-10-15 14:39 ` Andrea Bolognani
2018-10-15 16:59 ` Alistair Francis
2018-10-16 7:38 ` Andrea Bolognani
2018-10-16 14:11 ` Andrea Bolognani
2018-10-16 14:55 ` Andrea Bolognani
2018-10-16 17:31 ` Stephen Bates
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=20181011075544.GR27120@redhat.com \
--to=rjones@redhat.com \
--cc=Alistair.Francis@wdc.com \
--cc=abologna@redhat.com \
--cc=alistair23@gmail.com \
--cc=mjc@sifive.com \
--cc=palmer@sifive.com \
--cc=qemu-devel@nongnu.org \
--cc=stephen@eideticom.com \
/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).