>Forgot to mention that, despite showing up, the device doesn't quite
>work: for example, it can't seem to be able to acquire an IP address.
Andrea and Alistair
A lot of your issues look very similar to what I saw. The PCIe device can be
accessed via MMIO but interrupts are broken wh
On Tue, 2018-10-16 at 16:11 +0200, Andrea Bolognani wrote:
[...]
> If the network device is the only one
> using virtio-pci, though, despite still getting
>
> pci :00:01.0: BAR 0: no space for [io size 0x0020]
> pci :00:01.0: BAR 0: failed to assign [io size 0x0020]
>
> I can get al
On Tue, 2018-10-16 at 09:38 +0200, Andrea Bolognani wrote:
> On Mon, 2018-10-15 at 09:59 -0700, Alistair Francis wrote:
> > On Mon, Oct 15, 2018 at 7:39 AM Andrea Bolognani
> > wrote:
> > > One more thing that I forgot to bring up earlier: at the same time
> > > as PCIe support is added, we shoul
On Mon, 2018-10-15 at 09:59 -0700, Alistair Francis wrote:
> On Mon, Oct 15, 2018 at 7:39 AM Andrea Bolognani wrote:
> > One more thing that I forgot to bring up earlier: at the same time
> > as PCIe support is added, we should also make sure that the
> > pcie-root-port device is built into the qe
On Mon, Oct 15, 2018 at 7:39 AM Andrea Bolognani wrote:
>
> On Fri, 2018-10-12 at 09:12 -0700, Alistair Francis wrote:
> > On Fri, Oct 12, 2018 at 6:46 AM Andrea Bolognani
> > wrote:
> > > Problem solved then :)
> >
> > Does that mean you have it working?
>
> Yeah, it was trivial once I knew wha
On Fri, 2018-10-12 at 09:12 -0700, Alistair Francis wrote:
> On Fri, Oct 12, 2018 at 6:46 AM Andrea Bolognani wrote:
> > Problem solved then :)
>
> Does that mean you have it working?
Yeah, it was trivial once I knew what to look for ;)
One more thing that I forgot to bring up earlier: at the
On Fri, Oct 12, 2018 at 6:46 AM Andrea Bolognani wrote:
>
> On Thu, 2018-10-11 at 10:40 -0700, Alistair Francis wrote:
> > On Wed, Oct 10, 2018 at 11:00 PM Andrea Bolognani
> > wrote:
> > > The gpex-pcihost device was introduced at the same time as
> > > aarch64/virt gained PCI support, so we ca
On Thu, 2018-10-11 at 10:40 -0700, Alistair Francis wrote:
> On Wed, Oct 10, 2018 at 11:00 PM Andrea Bolognani wrote:
> > 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 aa
On Wed, Oct 10, 2018 at 11:00 PM 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 f
Hi All
> because that's the one that makes PCI_HOST_GENERIC available to
> non-ARM architectures.
You are going to need PCI_HOST_GENERIC for sure to get the drive for the GPEX
host PCIe port. I did my testing on a 4.19 based kernel [1] and the .config is
here [2] (sorry the link I sent for the
On Thu, 2018-10-11 at 12:45 +0100, Richard W.M. Jones wrote:
> On Thu, Oct 11, 2018 at 09:01:14AM +0100, Richard W.M. Jones wrote:
> > Here are the settings we currently do NOT have in my RV kernel:
> >
> > CONFIG_HOTPLUG_PCI_PCIE=y
> > CONFIG_HOTPLUG_PCI=y
> > CONFIG_MEDIA_PCI_SUPPORT=y
> > CONFI
On 11 October 2018 at 08:55, Richard W.M. Jones wrote:
> Can we ignore non-PCIe guests? virtio-mmio should die.
I note that Edgar's recent Xilinx Versal patchset adds a
new user of virtio-mmio. If that statement is meant to
apply generally it might be worth starting the discussion
in that patcht
On Thu, Oct 11, 2018 at 09:01:14AM +0100, Richard W.M. Jones wrote:
> Here are the settings we currently do NOT have in my RV kernel:
>
> CONFIG_HOTPLUG_PCI_PCIE=y
> CONFIG_HOTPLUG_PCI=y
> CONFIG_MEDIA_PCI_SUPPORT=y
> CONFIG_PCI_ATS=y
> CONFIG_PCI_DEBUG=y
> CONFIG_PCIEAER=y
> CONFIG_PCIEASPM_DEFAU
On Thu, Oct 11, 2018 at 07:59:59AM +0200, Andrea Bolognani wrote:
> On Wed, 2018-10-10 at 10:57 -0700, Alistair wrote:
> > I use this monolithic config:
> > https://github.com/alistair23/meta-riscv/blob/7a950aa705b439b5ec19bb6f094930888335ba7b/recipes-kernel/linux/files/freedom-u540/defconfig
> >
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
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 t
On Wed, 2018-10-10 at 12:53 -0700, Alistair wrote:
> On 10/10/2018 11:47 AM, Stephen Bates wrote:
> > > Strange. Is there any reason you need to use the e1000? The VirtIO
> > > networking device works for me.
> >
> > As per above. The e1000 is there to test PCIe not networking.
Unless I'
On 10/10/2018 12:01 PM, Stephen Bates wrote:
I added e1000 and e1000e support to my kernel and changed the QEMU command to:
So using -device e1000e rather than -device e1000 seems to work. I am not sure
why -device e1000 causes a kernel panic. The MSI-X message is interesting and
may be rela
On 10/10/2018 11:47 AM, Stephen Bates wrote:
Why do you need two networking options?
I don't need the e1000 for networking. The e1000 option is there to test the
PCIe since it implements a PCIe model of the e1000 NIC. Basically it's another
test path for your PCIe patches and was used
> I added e1000 and e1000e support to my kernel and changed the QEMU command to:
So using -device e1000e rather than -device e1000 seems to work. I am not sure
why -device e1000 causes a kernel panic. The MSI-X message is interesting and
may be related to why NVMe interrupts are not reaching the
>Why do you need two networking options?
I don't need the e1000 for networking. The e1000 option is there to test the
PCIe since it implements a PCIe model of the e1000 NIC. Basically it's another
test path for your PCIe patches and was used for testing when PCIe support to
the arm virt mod
On 10/10/2018 10:32 AM, Stephen Bates wrote:
I plan to also try with a e1000 network interface model tomorrow and see how
that behaves
Please do :)
I added e1000 and e1000e support to my kernel and changed the QEMU command to:
$QEMU -nographic \
-machine virt \
On 10/10/2018 05:26 AM, Andrea Bolognani wrote:
On Thu, 2018-10-04 at 20:06 +, Alistair Francis wrote:
Alistair Francis (5):
hw/riscv/virt: Increase the number of interrupts
hw/riscv/virt: Connect the gpex PCIe
riscv: Enable VGA and PCIE_VGA
hw/riscv/sifive_u: Connect the Xilinx
>> I plan to also try with a e1000 network interface model tomorrow and see how
>> that behaves
>
>Please do :)
I added e1000 and e1000e support to my kernel and changed the QEMU command to:
$QEMU -nographic \
-machine virt \
-smp 1 -m 8G \
-append "console=hvc0
>So it looks like you at least got to the point where the guest OS
>would find PCIe devices...
Yes and in fact NVMe IO against those devices do succeed (I can write and read
the NVMe namespaces). It is just slow because the interrupts are not getting to
the OS and hence NVMe timeouts are
On Wed, 2018-10-10 at 13:11 +, Stephen Bates wrote:
> I also tried these out but I was interested in seeing if I could create NVMe
> models inside the new PCIe subsystem (for both the virt and sifive_u
> machines). The sifive_u machine did not work at all (so I'll leave that one
> for now).
Andrea and Alistair
+Keith since he developed a lot of the NVMe drive model
>> Alistair Francis (5):
>> hw/riscv/virt: Increase the number of interrupts
>> hw/riscv/virt: Connect the gpex PCIe
>> riscv: Enable VGA and PCIE_VGA
>> hw/riscv/sifive_u: Connect the Xilinx P
On Thu, 2018-10-04 at 20:06 +, Alistair Francis wrote:
> Alistair Francis (5):
> hw/riscv/virt: Increase the number of interrupts
> hw/riscv/virt: Connect the gpex PCIe
> riscv: Enable VGA and PCIE_VGA
> hw/riscv/sifive_u: Connect the Xilinx PCIe
> hw/riscv/virt: Connect a VirtIO net
V5:
- Rebase
- Include pci.mak in the default configs
V4:
- Fix the spike device tree
- Don't use stdvga device
V3:
- Remove Makefile config changes
- Connect a network adapter to the virt device
V2:
- Use the gpex PCIe host for virt
- Add support for SiFive U PCIe
Alistair Francis (5):
29 matches
Mail list logo
