search for: gicv3

Hi I'm running Openstack which is installed by using devstack. But it is not launching VMs. >From command line with gic_version=3 option it is running. But openstack glance doesn't have any privilege to specify gic version. On my ARM64 board gicv2 is not supported, so i want to make gicv3 as default one to pass to qemu. Kindly suggest any specific version of vibvirt or patch such that libvirt should pass gicv3 as default one. Thanks in Advance -Vishnu.

...t; consolidator. > Consolidator can translate the legacy interrupts connected to it to > MSI/MSI-X. And new non-PCI device will be designed to support MSI in > future. So make the MSI driver code be generic will help the non-PCI > device use MSI more simply. As per my understanding the GICv3 provides a service that will convert writes to a specified address to IRQs delivered to the core and as you mention above MSIs are part of the PCI spec. So I can see a strong case for non-PCI devices to want MSI like functionality without being fully compliant with the requirements of the MSI spec....

...t; consolidator. > Consolidator can translate the legacy interrupts connected to it to > MSI/MSI-X. And new non-PCI device will be designed to support MSI in > future. So make the MSI driver code be generic will help the non-PCI > device use MSI more simply. As per my understanding the GICv3 provides a service that will convert writes to a specified address to IRQs delivered to the core and as you mention above MSIs are part of the PCI spec. So I can see a strong case for non-PCI devices to want MSI like functionality without being fully compliant with the requirements of the MSI spec....

...Consolidator can translate the legacy interrupts connected to it to >> MSI/MSI-X. And new non-PCI device will be designed to support MSI in >> future. So make the MSI driver code be generic will help the non-PCI >> device use MSI more simply. > > As per my understanding the GICv3 provides a service that will convert writes to a specified address to IRQs delivered to the core and as you mention above MSIs are part of the PCI spec. So I can see a strong case for non-PCI devices to want MSI like functionality without being fully compliant with the requirements of the MSI spec....

...de the "msi-parent" property per > device, but those can also use the global property. > > The main use case that I see are PCI host controllers that have their own MSI catcher > included, so meaning that any PCI device can either send its MSIs there, or to a > system-wide GICv3 instance, and we need a way to select which one. Yes, agree. > > A degenerate case of this would be a system where a PCI device sends its MSI into > the host controller, that generates a legacy interrupt and that in turn gets > sent to an irqchip which turns it back into an MSI for...

...de the "msi-parent" property per > device, but those can also use the global property. > > The main use case that I see are PCI host controllers that have their own MSI catcher > included, so meaning that any PCI device can either send its MSIs there, or to a > system-wide GICv3 instance, and we need a way to select which one. Yes, agree. > > A degenerate case of this would be a system where a PCI device sends its MSI into > the host controller, that generates a legacy interrupt and that in turn gets > sent to an irqchip which turns it back into an MSI for...

...uld be possible to override the "msi-parent" property per device, but those can also use the global property. The main use case that I see are PCI host controllers that have their own MSI catcher included, so meaning that any PCI device can either send its MSIs there, or to a system-wide GICv3 instance, and we need a way to select which one. A degenerate case of this would be a system where a PCI device sends its MSI into the host controller, that generates a legacy interrupt and that in turn gets sent to an irqchip which turns it back into an MSI for the GICv3. This would of course be...

On Thu, 28 Feb 2019 08:16:05 +0000, Greg KH <gregkh at linuxfoundation.org> wrote: Hi both, > > On Wed, Feb 27, 2019 at 04:36:39PM -0800, Daniel Verkamp wrote: > > Hello, > > > > In my testing of crosvm[1] with Linux 4.4.175, I am observing failures > > on a 'kevin' Chromebook (RK3399) device - the guest kernel does not > > even get to the

On Thu, 28 Feb 2019 08:16:05 +0000, Greg KH <gregkh at linuxfoundation.org> wrote: Hi both, > > On Wed, Feb 27, 2019 at 04:36:39PM -0800, Daniel Verkamp wrote: > > Hello, > > > > In my testing of crosvm[1] with Linux 4.4.175, I am observing failures > > on a 'kevin' Chromebook (RK3399) device - the guest kernel does not > > even get to the

...start a UP guest and drop you to a shell. In the > meantime, I'm starting to build crosvm on my kevin running mainline. OK, that wasn't a fun experience. Some build instructions for the mere mortals (aka non-ChromeOS people) would be nice (and a mention that crosvm cannot yet deal with GICv3-only systems...) Anyway, I've got enough of it working that I can boot a trivial Debian guest on kevin running 5.0-rc7, so I'm pretty confident that mainline is OK. I'll move back to 4.4, and try to understand what happens there. Thanks, M. -- Jazz is not dead. It just smells funny...

...te the legacy interrupts connected to it to > >> MSI/MSI-X. And new non-PCI device will be designed to support MSI in > >> future. So make the MSI driver code be generic will help the non-PCI > >> device use MSI more simply. > > > > As per my understanding the GICv3 provides a service that will convert writes > to a specified address to IRQs delivered to the core and as you mention above > MSIs are part of the PCI spec. So I can see a strong case for non-PCI devices to > want MSI like functionality without being fully compliant with the requirements &...

...te the legacy interrupts connected to it to > >> MSI/MSI-X. And new non-PCI device will be designed to support MSI in > >> future. So make the MSI driver code be generic will help the non-PCI > >> device use MSI more simply. > > > > As per my understanding the GICv3 provides a service that will convert writes > to a specified address to IRQs delivered to the core and as you mention above > MSIs are part of the PCI spec. So I can see a strong case for non-PCI devices to > want MSI like functionality without being fully compliant with the requirements &...

...ing and buffers at page granularity. Patch 3 implements the actual virtio-iommu device. Adding --viommu on the command-line now inserts a virtual IOMMU in front of all virtio and vfio devices: $ lkvm run -k Image --console virtio -p console=hvc0 \ --viommu --vfio 0 --vfio 4 --irqchip gicv3-its ... [ 2.998949] virtio_iommu virtio0: probe successful [ 3.007739] virtio_iommu virtio1: probe successful ... [ 3.165023] iommu: Adding device 0000:00:00.0 to group 0 [ 3.536480] iommu: Adding device 10200.virtio to group 1 [ 3.553643] iommu: Adding device 10600.virtio to...

On 2014/7/29 22:08, Arnd Bergmann wrote: > On Saturday 26 July 2014 11:08:37 Yijing Wang wrote: >> The series is a draft of generic MSI driver that supports PCI >> and Non-PCI device which have MSI capability. If you're not interested >> it, sorry for the noise. > > I've finally managed to take some time to look at the series. Overall, > the concept

On 2014/7/29 22:08, Arnd Bergmann wrote: > On Saturday 26 July 2014 11:08:37 Yijing Wang wrote: >> The series is a draft of generic MSI driver that supports PCI >> and Non-PCI device which have MSI capability. If you're not interested >> it, sorry for the noise. > > I've finally managed to take some time to look at the series. Overall, > the concept

...Patch 3 implements the actual virtio- > iommu device. > > Adding --viommu on the command-line now inserts a virtual IOMMU in front > of all virtio and vfio devices: > > $ lkvm run -k Image --console virtio -p console=hvc0 \ > --viommu --vfio 0 --vfio 4 --irqchip gicv3-its > ... > [ 2.998949] virtio_iommu virtio0: probe successful > [ 3.007739] virtio_iommu virtio1: probe successful > ... > [ 3.165023] iommu: Adding device 0000:00:00.0 to group 0 > [ 3.536480] iommu: Adding device 10200.virtio to group 1 > [ 3.553643] io...

...Patch 3 implements the actual virtio- > iommu device. > > Adding --viommu on the command-line now inserts a virtual IOMMU in front > of all virtio and vfio devices: > > $ lkvm run -k Image --console virtio -p console=hvc0 \ > --viommu --vfio 0 --vfio 4 --irqchip gicv3-its > ... > [ 2.998949] virtio_iommu virtio0: probe successful > [ 3.007739] virtio_iommu virtio1: probe successful > ... > [ 3.165023] iommu: Adding device 0000:00:00.0 to group 0 > [ 3.536480] iommu: Adding device 10200.virtio to group 1 > [ 3.553643] io...

...at we have to add one or two more arguments here. > > A degenerate case of this would be a system where a PCI device sends its MSI into > > the host controller, that generates a legacy interrupt and that in turn gets > > sent to an irqchip which turns it back into an MSI for the GICv3. This would of > > course be very inefficient, but I think we should be able to express this with > > both the binding and the in-kernel framework just to be on the safe side. > > Yes, the best way to tell the kernel which msi_chip should deliver to is describe > the binding i...

...d-balancing, hardware offload and other advanced features. A basic patch set has already been committed to head including: * PCIe Root Complex support * Cache Coherency Unit driver * North Bridge Service driver * Updated Alpine HAL * Extended MSI support in GICv2 and GICv3 code Additional work, such as an MSI-X driver and full Ethernet support, is currently undergoing community review on Phabricator. The multi-user SMP system is stable and fully working, along with the 1G and 10G Ethernet links. The interrupt management code has been adjusted to wor...

...d-balancing, hardware offload and other advanced features. A basic patch set has already been committed to head including: * PCIe Root Complex support * Cache Coherency Unit driver * North Bridge Service driver * Updated Alpine HAL * Extended MSI support in GICv2 and GICv3 code Additional work, such as an MSI-X driver and full Ethernet support, is currently undergoing community review on Phabricator. The multi-user SMP system is stable and fully working, along with the 1G and 10G Ethernet links. The interrupt management code has been adjusted to wor...