[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1415812284.16601.372.camel@ul30vt.home>
Date: Wed, 12 Nov 2014 10:11:24 -0700
From: Alex Williamson <alex.williamson@...hat.com>
To: Paolo Bonzini <pbonzini@...hat.com>
Cc: "Zhang, Yang Z" <yang.z.zhang@...el.com>,
"Wu, Feng" <feng.wu@...el.com>,
"gleb@...nel.org" <gleb@...nel.org>,
"dwmw2@...radead.org" <dwmw2@...radead.org>,
"joro@...tes.org" <joro@...tes.org>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"mingo@...hat.com" <mingo@...hat.com>,
"hpa@...or.com" <hpa@...or.com>, "x86@...nel.org" <x86@...nel.org>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"eric.auger" <eric.auger@...aro.org>
Subject: Re: [PATCH 05/13] KVM: Update IRTE according to guest interrupt
configuration changes
On Wed, 2014-11-12 at 10:14 +0100, Paolo Bonzini wrote:
>
> On 12/11/2014 04:42, Zhang, Yang Z wrote:
> > Personally, I think this feature will be helpful to the legacy device
> > assignment. Agree, vfio is the right solution for future feature
> > enabling. But the old kvm without the good vfio supporting is still
> > used largely today. The user really looking for this feature but they
> > will not upgrade their kernel. It's easy for us to backport this
> > feature to old kvm with the legacy device assignment, but it is
> > impossible to backport the whole vfio.
>
> You can certainly backport these patches to distros that do not have
> VFIO. But upstream we should work on VFIO first. VFIO has feature
> parity with legacy device assignment, and adding a new feature that is
> not in VFIO would be a bad idea.
Thanks Paolo, I agree. We should design the interfaces for VFIO since
we expect legacy KVM assignment to be deprecated and eventually removed.
I think that some of the platform device work for ARM's IRQ forwarding
should probably be leveraged for this interface. IRQ forwarding
effectively allows level triggered interrupts to be handled as edge,
eliminating the mask/unmask overhead and EOI path entirely. To do this
through VFIO they make use of the KVM-VFIO device to register the device
and set attributes for the forwarded IRQ. This enables KVM to use the
VFIO external user interfaces to acquire a VFIO device reference and
access the struct device. From there it can do some IRQ manipulation on
the device to reconfigure how the host handles the interrupt. Ideally
we could use the same base KVM-VFIO device interface interface, perhaps
with different attributes, and obviously with different architecture
backing. Thanks,
Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists