On Wed, Oct 10, 2018 at 11:00 PM Andrea Bolognani <abolo...@redhat.com> 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 :)
The device shouldn't exist in the RISC-V QEMU binary though until after this patch series. So it should have the same effect. Alistair > > Is there any RISC-V device / property that was introduced along > with PCI support and we can use as a witness? > > > > * 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. > > [...] > > Obviously on top of that you will need to enable the VirtIO support as > > that doesn't exist in the hardware. > > Yeah, we already have that enabled and non-PCI VirtIO devices work > just fine. > > > [1] Not the guest, mind you: libvirt will probe each QEMU binary only > once to reduce the overhead, so anyth > -- > Andrea Bolognani / Red Hat / Virtualization >
