From: "Michael S. Tsirkin" <mst@redhat.com>
To: Jan Kiszka <jan.kiszka@web.de>
Cc: Alex Williamson <alex.williamson@redhat.com>,
Le Tan <tamlokveer@gmail.com>, qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] vfio in the guest: no available reset mechanism
Date: Mon, 4 Aug 2014 14:43:58 +0200 [thread overview]
Message-ID: <20140804124358.GE15491@redhat.com> (raw)
In-Reply-To: <53DC7D16.1050509@web.de>
On Sat, Aug 02, 2014 at 07:54:30AM +0200, Jan Kiszka wrote:
> On 2014-08-01 19:16, Alex Williamson wrote:
> >> Also, it may let some of our device
> >> models deviate from their real versions (I suppose, e.g., none of the
> >> e1000 devices we currently emulate exposed FLR).
> >
> > Of course, but what are the chances that the driver will care?
>
> No drivers of GPOSes, but special or legacy OSes may do so. Keep in mind
> that Intel e.g. is documenting their PCI devices with fixed config space
> addresses for their capability.
>
> Also, we completely lack PM caps so far. Adding them would already have
> the value of increasing emulation accuracy. And here I think we are free
> to always implement reset behavior behind D3->D0 transitions. So my
> believe is that this will be the better path.
>
> Jan
>
>
That's true but is PM reset per-function or per-device?
I'll have to check the spec - do you happen to rememeber?
next prev parent reply other threads:[~2014-08-04 12:43 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-30 12:24 [Qemu-devel] vfio in the guest: no available reset mechanism Le Tan
2014-07-30 13:16 ` Michael S. Tsirkin
2014-07-30 14:16 ` Le Tan
2014-07-30 14:46 ` Alex Williamson
2014-08-01 1:35 ` Le Tan
2014-08-01 15:25 ` Alex Williamson
2014-08-01 16:35 ` Alex Williamson
2014-08-01 16:39 ` Jan Kiszka
2014-08-01 17:16 ` Alex Williamson
2014-08-02 5:54 ` Jan Kiszka
2014-08-04 12:43 ` Michael S. Tsirkin [this message]
2014-08-01 22:58 ` Le Tan
2014-07-30 14:49 ` 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=20140804124358.GE15491@redhat.com \
--to=mst@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=jan.kiszka@web.de \
--cc=qemu-devel@nongnu.org \
--cc=tamlokveer@gmail.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.