All of lore.kernel.org
 help / color / mirror / Atom feed
From: Etienne Martineau <etmartin101@gmail.com>
To: Chris Wright <chrisw@sous-sol.org>
Cc: 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 15:08:18 -0700 (PDT)	[thread overview]
Message-ID: <alpine.DEB.2.00.1010261423520.4117@ubuntu.ubuntu-domain> (raw)
In-Reply-To: <20101026204208.GV25455@sequoia.sous-sol.org>



On Tue, 26 Oct 2010, Chris Wright wrote:

>> ***One of the aspect I'm not clear is the strategy for
>> device-assignment under KVM?
>> A) Move to VFIO; [/dev/iommu, /dev/vfio]
>
> Long term, hopefully VFIO
>
>> B) KVM as a driver for the assigned devices; [sysfs/ ioctls..]
>
> Short term (i.e. current qemu-kvm tree...this is what we have now and
> will continue to until plan A) gets more mature).
>
Strictly speaking, I don't really agree with 'B' being the current 
implementation. Correct me if I'm wrong but for assigned devices, kvm 
does a look up for the device and eventually obtain a handle to it (struct 
pci_dev*) without doing a proper 'pci_register_driver'.

I think we need to register with PCI and provide 'pci_error_handlers' 
callback if we wants to receive AER notification.

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...

Thanks,
Etienne



  reply	other threads:[~2010-10-26 22:08 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 [this message]
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
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=alpine.DEB.2.00.1010261423520.4117@ubuntu.ubuntu-domain \
    --to=etmartin101@gmail.com \
    --cc=alex.williamson@redhat.com \
    --cc=chrisw@sous-sol.org \
    --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.