All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Wright <chrisw@sous-sol.org>
To: Etienne Martineau <etmartin101@gmail.com>
Cc: Chris Wright <chrisw@sous-sol.org>,
	Alex Williamson <alex.williamson@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	kvm@vger.kernel.org
Subject: Re: KVM devices assignment; PCIe AER?
Date: Tue, 26 Oct 2010 16:05:52 -0700	[thread overview]
Message-ID: <20101026230552.GA25455@sequoia.sous-sol.org> (raw)
In-Reply-To: <alpine.DEB.2.00.1010261519310.2450@localhost.localdomain>

* Etienne Martineau (etmartin101@gmail.com) wrote:
> On Tue, 26 Oct 2010, Chris Wright wrote:
> >Right, and adding more to the existing KVM code which we are hoping to
> >push to legacy support mode doesn't sound like a great idea.
> 
> I would totally agree with you if the alternative implementation to
> this legacy mode would be available in a relatively short time
> frame. I'm not sure about that?

Depends on how quickly you can help whip it into shape ;)

That's why I asked about how you were implementing, for example, the AER
extended capability exposure.  Capabilities are a problem for the current
code (forget about extended capabilities, just regular capabilities).

> >>In that context, do you think it's acceptable for KVM to be the
> >>driver of the assigned devices? OR should we simply add the AER
> >>logic into existing pci-stub and relay the information to user-space
> >>through eventfd...
> >
> >I'm reluctant to add logic to pci-stub, but VFIO should be able to
> >handle this directly.
>
> I agree that VFIO should be able to do the job.

It would be great to see some effort on this.

thanks,
-chris

  reply	other threads:[~2010-10-26 23:06 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-26 16:41 KVM devices assignment; PCIe AER? etmartin101
2010-10-26 18:10 ` Alex Williamson
2010-10-26 18:21 ` Chris Wright
2010-10-26 18:37 ` Michael S. Tsirkin
2010-10-26 20:24   ` Etienne Martineau
2010-10-26 20:42     ` Chris Wright
2010-10-26 22:08       ` Etienne Martineau
2010-10-26 22:15         ` Chris Wright
2010-10-26 22:17           ` Michael S. Tsirkin
2010-10-26 22:47           ` Etienne Martineau
2010-10-26 23:05             ` Chris Wright [this message]
2010-10-27  3:51               ` Etienne Martineau
2010-10-27 14:54                 ` Alex Williamson
2010-10-27 18:23                   ` Etienne Martineau
2010-10-27 19:16                     ` Alex Williamson
2010-10-27 21:43                       ` Etienne Martineau
2010-10-27 22:58                         ` Alex Williamson
2010-10-28  4:58                           ` Michael S. Tsirkin
2010-10-28  5:17                             ` Alex Williamson
2010-10-28  5:39                               ` Michael S. Tsirkin
2010-10-28 23:36                           ` Etienne Martineau
2010-10-26 20:54     ` Michael S. Tsirkin
2010-10-26 18:38 ` Michael S. Tsirkin

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=20101026230552.GA25455@sequoia.sous-sol.org \
    --to=chrisw@sous-sol.org \
    --cc=alex.williamson@redhat.com \
    --cc=etmartin101@gmail.com \
    --cc=kvm@vger.kernel.org \
    --cc=mst@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.